This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Win32 gdbserver new interrupt support, and attach to process fix.


Pedro Alves escreveu:
Lerele wrote:

It seems after all the solution proposed may be the best resort, instead of the last: more compatible, less interfereable with child, however a bit more difficult to write.
In fact, the first version of interrupt code I wrote several months ago worked like that (I still keep a copy somewhere). It worked, but it was buggy, so I dropped it and wrote that other simpler new version.
This other solution may be the one-for-all solution, because it uses rather more standard Win32 calls.

The more I search for a *clean* way to do it in WinCE, the more I'm
inclined to drop the create_a_remote_thread idea. A bit of
googling and reading old MSFT docs indicates that older debuggers either
suspend all threads with SuspendThread (like you suggest, or get the
main thread's PC (EIP) and set a breakpoint there, which should be
simpler. (I would still have to do a little more work for WinCE
because the address might not be physically writable.) I think I
read somewhere that recent MSVC uses DebugBreakProcess, and hides the fact
that the break was inside ntdll.dll, or wherever, by switching threads...


What do you think of just suspending of thread, and setting a breakpoint
at the current PC, and resuming?


The GoVest debugger (*) uses something even simpler: - Suspend main thread, - Set single-step / trace flag (i386) - Resume thread

(*) http://www.geocities.com/GoVest/

Cheers,
Pedro Alves



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]