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 wrote:
What do you think of just suspending of thread, and setting a breakpoint
at the current PC, and resuming?


Errrh, don't even bother to answer this question. This method is of course very
fallible. The thread may be blocked on IO or on a synchronization object, which is
common in windows code (waiting for events). If the thread doesn't get scheduled,
the breakpoint won't be hit. There may not be any thread that is a got candidate
for the breakpoint - like if you have all your threads either deadlock or blocked.
The beauty of injecting a remote thread, is that it stops all the inferior threads atomically,
with minimum interference. That leaves:


- ctrl-c event, which in some cases doesn't get through.
- DebugBreakProcess, on XP and 2003 Server and emulating it on NT < 5 / Win9x/ME / CE
using code injection. One case where it could disturb the inferior would be
when you can't debug a DllMain because of the CREATE_THREAD_EVENT that
this generates, or is there a way to inhibit its propagation?
- 'suspend all threads manually, but no breakpoint' method.


What about using the version you sent (if approved), and then work on
this new version on top? IMHO, it is better to have something working
first. (I don't believe the extra thread makes a difference 99.999999999%
of the times.)
This is still my opinion.

Cheers,
Pedro Alves



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