This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [RFC] win32-nat.c 'set new-console' and interruption
> -----Message d'origine-----
> De?: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pedro Alves
> Envoyé?: Monday, June 23, 2008 4:41 PM
> À?: gdb-patches@sourceware.org
> Cc?: Pierre Muller
> Objet?: Re: [RFC] win32-nat.c 'set new-console' and interruption
>
> A Monday 23 June 2008 15:23:06, Pierre Muller wrote:
>
> > I have a proposal to remove that possible race condition:
> > The exception record has a field that contains the exception
> > address, if I test that there is no GDB inserted breakpoint at
> > that location before converting the TARGET_SIGNAL_TRAP
> > into a TARGET_SIGNAL_INT, it should fix most problems, no?
> >
> > The one case that it would still not catch would be
> > a 'int 3' instruction that is in the debuggee code from the start
> > but other than at startup, such instructions are quite unlikely, no?
> >
>
> IIRC, DebugBreakProcess injects a thread in the debuggee and
> always breaks at the same address / in the same function -- I don't
> know if there's a hardcoded 0xcc at the break address you
> could check, or if the exception is generated programatically,
> but at least you could conditionalize on the function name (if there's
> no hardcoded break, you still can't distiguish by name only a user
> break placed in that special break function)
I checked this: on windows XP it does use an 'int 3' instruction
that is situated in ntdll DLL at an exported function named
DbgUiConnectToDbg, but I would really like to avoid hard-coding this into
win32-nat.c as there is no assurance that other versions of
Microsoft OS will use the same function.
> Another option is to use SuspendThread on all threads to stop
> the process, which is what I believe Visual Studio uses.
> gdbserver has that implemented for systems that don't have
> DebugBreakProcess.
That is also a nice idea...
The only problem in that case is, which thread do we then
use as the current_thread?
Do we default on main_thread_id?
But the current win32-nat source code has a particularity
here: it never removes the main_thread_idd thread
even if that thread exits, I don't really know
why it was coded like this but that means that using
main_thread_id might put us in a 'dead' thread.
I never managed to send a patch for this,
and I suspect that there are some hidden reason for
this strange behavior!
We could insert code that stops all threads into
win32_wait at the location of the
deprecated_ui_loop_hook code,
but I don't know really how to handle this:
if you suspend manually all threads, you can of course
set ourstatus, but the question is how do you coordinate this
with the next call to win32_resume?
Is it enough to add a global variable
threads_suspended_manually (not sure this is the best name)
and to add something like
if (!threads_suspended_manually)
res = ContinueDebugEvent (...)
else
/* Here we add the code to resume all threads */
If fear that we might need more special code, for instance if
win32_resume is called with a non zero signal to pass,
which would of course be impossible in that case.
I would personally prefer to postpone this
to a later patch, but Christopher should
tell us what the best way is.
Pierre Muller
Pascal language support maintainer for GDB