Debugging GNU Emacs on MS Windows / getting control back to gdb

Debugging GNU Emacs on MS Windows / getting control back to gdb

[Alain Schneble]

Hello

When debugging GNU Emacs using gdb or gud-gdb on MS Windows, is there a
way to return control back to GDB at any point in time by suspending the
debuggee process -- without setting any breakpoint upfront?

There is a section "Getting control to the debugger" in ./etc/DEBUG, but
I can't figure out how to do this on MS Windows.  I suspect it must be
possible somehow...

Thanks for any help!
Alain

Re: Debugging GNU Emacs on MS Windows / getting control back to gdb

[Eli Zaretskii]

> From: Alain Schneble <a.s@realize.ch>
> Date: Sun, 21 Aug 2016 18:09:57 +0200
> 
> When debugging GNU Emacs using gdb or gud-gdb on MS Windows, is there a
> way to return control back to GDB at any point in time by suspending the
> debuggee process -- without setting any breakpoint upfront?

Not really, no.

But what's the problem of setting a breakpoint up front?

Re: Debugging GNU Emacs on MS Windows / getting control back to gdb

[Alain Schneble]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alain Schneble <a.s@realize.ch>
>> Date: Sun, 21 Aug 2016 18:09:57 +0200
>> 
>> When debugging GNU Emacs using gdb or gud-gdb on MS Windows, is there a
>> way to return control back to GDB at any point in time by suspending the
>> debuggee process -- without setting any breakpoint upfront?
>
> Not really, no.
>
> But what's the problem of setting a breakpoint up front?

I just wanted to step through `Fappend'.  But it's called a lot.  It
would have been much easier to just arrange for the state manually, then
suspend, set the breakpoint in Fappend and eval my elisp function that
calls the Fappend I'm interested in.  That sounded much easier to me
than configuring proper conditions on the breakpoint.  As an
alternative, I could have put a breakpoint on a rarly called function
such as Fredraw_display, as suggested in ./etc/DEBUG.  But that felt
more like a workaround as well.  Or is there yet another (better)
approach?

Thanks.
Alain

Re: Debugging GNU Emacs on MS Windows / getting control back to gdb

[Eli Zaretskii]

> From: Alain Schneble <a.s@realize.ch>
> Date: Sun, 21 Aug 2016 18:38:57 +0200
> Cc: emacs-devel@gnu.org
> 
> As an alternative, I could have put a breakpoint on a rarly called
> function such as Fredraw_display, as suggested in ./etc/DEBUG.  But
> that felt more like a workaround as well.

It's not a workaround, it's the real thing.

And even that might not be enough for a frequently called function.
Then you need to make the breakpoint conditional on some input values,
or the value of point, or whatever else can filter out hits you don't
want.

Re: Debugging GNU Emacs on MS Windows / getting control back to gdb

[Alain Schneble]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alain Schneble <a.s@realize.ch>
>> Date: Sun, 21 Aug 2016 18:38:57 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> As an alternative, I could have put a breakpoint on a rarly called
>> function such as Fredraw_display, as suggested in ./etc/DEBUG.  But
>> that felt more like a workaround as well.
>
> It's not a workaround, it's the real thing.

Ok.

> And even that might not be enough for a frequently called function.
> Then you need to make the breakpoint conditional on some input values,
> or the value of point, or whatever else can filter out hits you don't
> want.

But that was exactly my point, that it is more cumbersome to setup a
conditional breakpoint.  Whereas with a process suspension, I only have
to set an unconditional breakpoint and then continue execution.  Of
course, this works well only if I know that the next call to the
function is the one call I'm interested in.

Re: Debugging GNU Emacs on MS Windows / getting control back to gdb

[Eli Zaretskii]

> From: Alain Schneble <a.s@realize.ch>
> CC: <emacs-devel@gnu.org>
> Date: Sun, 21 Aug 2016 21:06:36 +0200
> 
> > And even that might not be enough for a frequently called function.
> > Then you need to make the breakpoint conditional on some input values,
> > or the value of point, or whatever else can filter out hits you don't
> > want.
> 
> But that was exactly my point, that it is more cumbersome to setup a
> conditional breakpoint.

Nevertheless, it's frequently a necessity.

> Whereas with a process suspension, I only have to set an
> unconditional breakpoint and then continue execution.  Of course,
> this works well only if I know that the next call to the function is
> the one call I'm interested in.

Exactly.  And you can never know that in advance, not with functions
called frequently.

Re: Debugging GNU Emacs on MS Windows / getting control back to gdb

[Alain Schneble]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alain Schneble <a.s@realize.ch>
>> Date: Sun, 21 Aug 2016 18:09:57 +0200
>> 
>> When debugging GNU Emacs using gdb or gud-gdb on MS Windows, is there a
>> way to return control back to GDB at any point in time by suspending the
>> debuggee process -- without setting any breakpoint upfront?
>
> Not really, no.

Actually, I just found
http://www.mingw.org/wiki/Workaround_for_GDB_Ctrl_C_Interrupt, compiled
it and it works!

This allows us to call debugbreak.exe [PID] and control goes back to
gdb!

Alain

Re: Debugging GNU Emacs on MS Windows / getting control back to gdb

[Eli Zaretskii]

> From: Alain Schneble <a.s@realize.ch>
> Date: Sun, 21 Aug 2016 18:46:11 +0200
> Cc: emacs-devel@gnu.org
> 
> Actually, I just found
> http://www.mingw.org/wiki/Workaround_for_GDB_Ctrl_C_Interrupt, compiled
> it and it works!
> 
> This allows us to call debugbreak.exe [PID] and control goes back to
> gdb!

How is this different from "gdb -p PID"?

Re: Debugging GNU Emacs on MS Windows / getting control back to gdb

[Alain Schneble]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alain Schneble <a.s@realize.ch>
>> Date: Sun, 21 Aug 2016 18:46:11 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> Actually, I just found
>> http://www.mingw.org/wiki/Workaround_for_GDB_Ctrl_C_Interrupt, compiled
>> it and it works!
>> 
>> This allows us to call debugbreak.exe [PID] and control goes back to
>> gdb!
>
> How is this different from "gdb -p PID"?

Please correct me if I'm wrong, but that works only once, just after
attaching to the process.  But if I then continue execution, there is no
way to again suspend the process and return control to GDB.

Re: Debugging GNU Emacs on MS Windows / getting control back to gdb

[Eli Zaretskii]

> From: Alain Schneble <a.s@realize.ch>
> CC: <emacs-devel@gnu.org>
> Date: Sun, 21 Aug 2016 21:08:52 +0200
> 
> >> Actually, I just found
> >> http://www.mingw.org/wiki/Workaround_for_GDB_Ctrl_C_Interrupt, compiled
> >> it and it works!
> >> 
> >> This allows us to call debugbreak.exe [PID] and control goes back to
> >> gdb!
> >
> > How is this different from "gdb -p PID"?
> 
> Please correct me if I'm wrong, but that works only once, just after
> attaching to the process.  But if I then continue execution, there is no
> way to again suspend the process and return control to GDB.

No, you misunderstand me.  I think when you attach the second GDB, the
first one gets control.  No?

Re: Debugging GNU Emacs on MS Windows / getting control back to gdb

[Alain Schneble]

Eli Zaretskii <eliz@gnu.org> writes:

>> > How is this different from "gdb -p PID"?
>> 
>> Please correct me if I'm wrong, but that works only once, just after
>> attaching to the process.  But if I then continue execution, there is no
>> way to again suspend the process and return control to GDB.
>
> No, you misunderstand me.  I think when you attach the second GDB, the
> first one gets control.  No?

Hmm.  That doesn't work on my machine.  Second gdb that I try to attach
to the same debugee gets "Can't attach to process" error.  And the first
gdb instance doesn't notice anything...