GNU bug report logs - #79144
[PATCH] New debugger-trap function to break to GDB

Previous Next

To reply to this bug, email your comments to 79144 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeremy Bryant <jb <at> jeremybryant.net>
To: bug-gnu-emacs <at> gnu.org
Cc: , Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: [PATCH] New debugger-trap function to break to GDB
Date: Sat, 02 Aug 2025 00:19:26 +0100

[Message part 1 (text/plain, inline)]

Here is a patch to add a default command debugger-trap to break into
GDB, together with a default breakpoint set in .gdbinit
The immediate benefit for developers is a standard command to use where
there isn't one at the moment, as explained in DEBUG, only general guidance.

The long-term benefit is it can be the foundation for further work to
enhance debugging in Emacs with GDB, with the ability to
programmatically break into GDB, something I am working on as part of
C/Lisp hybrid debugging aids.


This patch has received substantial advice and reviewed by Eli.  It is
posted here for the benefit of the community for further discussion.

To recap, we need a do-nothing primitive, whose sole purpose is to
allow setting a breakpoint there to get control to GDB.
redraw-display and similar functions are usually okay, but they could
 get in the way if what they do modifies Emacs in a way that interferes
with debugging, for example if they remove some display artifact one
is debugging, or run functions as side effect that modify the global
state.


Adding Paul Eggert as the main recent contributor to etc/DEBUG for thoughts.

[0001-New-debugger-trap-function-to-break-to-GDB.patch (text/x-diff, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jeremy Bryant <jb <at> jeremybryant.net>, bug-gnu-emacs <at> gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: [PATCH] New debugger-trap function to break to GDB
Date: Fri, 1 Aug 2025 17:29:32 -0700

On 2025-08-01 16:19, Jeremy Bryant wrote:
> redraw-display and similar functions are usually okay, but they could
>   get in the way if what they do modifies Emacs in a way that interferes
> with debugging

In the past I've used Facos for this purpose, under the theory that 
nobody ever calls acos so I know a breakpoint there means I want the 
debugger trap.

With that in mind I suggest documenting in the doc string that Emacs 
never calls this function except to do X, Y and Z, where X Y and Z are 
spelled out clearly. (I assume X Y and Z all have to do with debugging.)

Also, shouldn't there  be something about the new function in 
doc/lispref/debugging.texi?

Message #11 received at 79144 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Jeremy Bryant <jb <at> jeremybryant.net>, 79144 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#79144: [PATCH] New debugger-trap function to break to GDB
Date: Fri, 1 Aug 2025 19:54:03 -0700

On 8/1/2025 4:19 PM, Jeremy Bryant via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Here is a patch to add a default command debugger-trap to break into
> GDB, together with a default breakpoint set in .gdbinit
> The immediate benefit for developers is a standard command to use where
> there isn't one at the moment, as explained in DEBUG, only general guidance.

This looks like a good idea. It might be useful to document more 
thoroughly that this is for setting a breakpoint in GDB and friends, 
rather than in the Elisp debugger. (Unless the plan is to support the 
Elisp debugger too somehow?)

Message #14 received at 79144 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: jb <at> jeremybryant.net, 79144 <at> debbugs.gnu.org
Subject: Re: [PATCH] New debugger-trap function to break to GDB
Date: Sat, 02 Aug 2025 10:02:51 +0300

> Date: Fri, 1 Aug 2025 17:29:32 -0700
> Cc: Eli Zaretskii <eliz <at> gnu.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> Also, shouldn't there  be something about the new function in 
> doc/lispref/debugging.texi?

That part of the manual doesn't currently describe debugging Emacs
with GDB.  When Jeremy finishes his work on C/Lisp hybrid debugging,
the techniques that supports should indeed be added to that part of
the manual.

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeremy Bryant <jb <at> jeremybryant.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-gnu-emacs <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: [PATCH] New debugger-trap function to break to GDB
Date: Sat, 02 Aug 2025 21:10:14 +0100

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 2025-08-01 16:19, Jeremy Bryant wrote:
>> redraw-display and similar functions are usually okay, but they could
>>   get in the way if what they do modifies Emacs in a way that interferes
>> with debugging
>
> In the past I've used Facos for this purpose, under the theory that
> nobody ever calls acos so I know a breakpoint there means I want the
> debugger trap.
>
> With that in mind I suggest documenting in the doc string that Emacs
> never calls this function except to do X, Y and Z, where X Y and Z are
> spelled out clearly. (I assume X Y and Z all have to do with
> debugging.)

Thanks, the doc string currently says this:

       doc: /* Trap execution flow and hand over control to GDB.
To use, set up a breakpoint to this function from GDB.
The function itself is a do-nothing primitive.  */)


Would the following clarification be clearer from your perspective?

       doc: /* Trap execution flow and hand over control to GDB.
To use, set up a breakpoint in GDB with 
break Fdebugger_trap
This is done in the Emacs source distribution in src/.gdbinit.

The function itself is a do-nothing primitive.  It is reserved for
debugging purposes, and not called by Emacs otherwise.  */)

Message #20 received at 79144 <at> debbugs.gnu.org (full text, mbox):

From: Jeremy Bryant <jb <at> jeremybryant.net>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 79144 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79144: [PATCH] New debugger-trap function to break to GDB
Date: Sat, 02 Aug 2025 21:21:15 +0100

Jim Porter <jporterbugs <at> gmail.com> writes:

> On 8/1/2025 4:19 PM, Jeremy Bryant via Bug reports for GNU Emacs, the
> Swiss army knife of text editors wrote:
>> Here is a patch to add a default command debugger-trap to break into
>> GDB, together with a default breakpoint set in .gdbinit
>> The immediate benefit for developers is a standard command to use where
>> there isn't one at the moment, as explained in DEBUG, only general guidance.
>
> This looks like a good idea. It might be useful to document more
> thoroughly that this is for setting a breakpoint in GDB and friends,
> rather than in the Elisp debugger. (Unless the plan is to support the
> Elisp debugger too somehow?)

Thanks, maybe this can be clarified - what makes you think of elisp
debugging in this version?  The file debug.el?

From a user point of view, the proposed docstring doesn't mention Elisp,
only GDB.

It is proposed for debug.el (not edebug.el), for this generality, and
due to the natural fit in this file, although admittedly.

;;; debug.el --- debuggers and related commands for Emacs


Beyond the immediate benefit to developers, the plan and prototype is to
use the Lisp debugger debug or edebug to then have the hybrid debugging,
so that choice of file also makes sense for this future plan.

Message #23 received at 79144 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Jeremy Bryant <jb <at> jeremybryant.net>
Cc: 79144 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#79144: [PATCH] New debugger-trap function to break to GDB
Date: Sat, 2 Aug 2025 13:57:58 -0700

On 8/2/2025 1:21 PM, Jeremy Bryant via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Thanks, maybe this can be clarified - what makes you think of elisp
> debugging in this version?  The file debug.el?

Initially, just reading the patch, the notes in etc/DEBUG didn't mention 
which debugger, but after reading the rest of that file, I see the 
context is clearer there.

For the 'debugger-trap' docstring though, it could be useful to point to 
the 'debug' command (which is roughly the Elisp debugger's equivalent), 
and possibly vice-versa. That way users can get redirected to the 
correct function from either docstring.

> Beyond the immediate benefit to developers, the plan and prototype is to
> use the Lisp debugger debug or edebug to then have the hybrid debugging,
> so that choice of file also makes sense for this future plan.

That would be very nice indeed. Debugging/instrumenting across the 
C/Lisp boundary is something I've never managed to do, and having a 
straightforward way to set it up would help a lot.

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jeremy Bryant <jb <at> jeremybryant.net>
Cc: bug-gnu-emacs <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: [PATCH] New debugger-trap function to break to GDB
Date: Sun, 3 Aug 2025 08:42:19 -0700

On 2025-08-02 13:10, Jeremy Bryant wrote:
> Would the following clarification be clearer from your perspective?
> 
>         doc: /* Trap execution flow and hand over control to GDB.
> To use, set up a breakpoint in GDB with
> break Fdebugger_trap
> This is done in the Emacs source distribution in src/.gdbinit.
> 
> The function itself is a do-nothing primitive.  It is reserved for
> debugging purposes, and not called by Emacs otherwise.  */)

Yes, thanks. Some minor wording tweaks, which make it easier for me to 
understand:

Trap execution flow and hand over control to GDB. The Emacs source file 
src/.gdbinit uses this via the GDB command "break Fdebugger trap".

This function has no effect.  It is reserved for debugging, and is not 
called by Emacs otherwise.

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeremy Bryant <jb <at> jeremybryant.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Jim Porter <jporterbugs <at> gmail.com>, bug-gnu-emacs <at> gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: [PATCH] New debugger-trap function to break to GDB
Date: Sun, 03 Aug 2025 22:41:18 +0100

[Message part 1 (text/plain, inline)]

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> On 2025-08-02 13:10, Jeremy Bryant wrote:
>> Would the following clarification be clearer from your perspective?
>>         doc: /* Trap execution flow and hand over control to GDB.
>> To use, set up a breakpoint in GDB with
>> break Fdebugger_trap
>> This is done in the Emacs source distribution in src/.gdbinit.
>> The function itself is a do-nothing primitive.  It is reserved for
>> debugging purposes, and not called by Emacs otherwise.  */)
>
> Yes, thanks. Some minor wording tweaks, which make it easier for me to
> understand:
>
> Trap execution flow and hand over control to GDB. The Emacs source
> file src/.gdbinit uses this via the GDB command "break Fdebugger
> trap".
>
> This function has no effect.  It is reserved for debugging, and is not
> called by Emacs otherwise.

OK, revised patch attached for consideration.

The change is in the docstring, incorporating your suggestion, Paul, as
well as the addition proposed by Jim, at the end.

What do people think of this change now?



Extract of patch for the docstring:-

DEFUN ("debugger-trap", Fdebugger_trap, Sdebugger_trap, 0, 0, "",
       doc: /* Trap execution flow and hand over control to GDB.
The Emacs source file src/.gdbinit uses this via the GDB command
"break Fdebugger_trap".

This function has no effect.  It is reserved for debugging, and is not
called by Emacs otherwise.

For Lisp debugging see debug, as well as edebug, in the manual:
"(elisp) Debugging".  */)
  (void)
{
  return Qnil;
}

[0001-New-debugger-trap-function-to-break-to-GDB.patch (text/x-diff, attachment)]

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jeremy Bryant <jb <at> jeremybryant.net>
Cc: Jim Porter <jporterbugs <at> gmail.com>, bug-gnu-emacs <at> gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: [PATCH] New debugger-trap function to break to GDB
Date: Sun, 3 Aug 2025 15:01:22 -0700

Thanks, looks good to me.

Message #37 received at 79144-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jeremy Bryant <jb <at> jeremybryant.net>
Cc: jporterbugs <at> gmail.com, 79144-done <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: [PATCH] New debugger-trap function to break to GDB
Date: Thu, 07 Aug 2025 16:40:34 +0300

> From: Jeremy Bryant <jb <at> jeremybryant.net>
> Cc: bug-gnu-emacs <at> gnu.org,  Eli Zaretskii <eliz <at> gnu.org>, Jim Porter
>  <jporterbugs <at> gmail.com>
> Date: Sun, 03 Aug 2025 22:41:18 +0100
> 
> OK, revised patch attached for consideration.
> 
> The change is in the docstring, incorporating your suggestion, Paul, as
> well as the addition proposed by Jim, at the end.
> 
> What do people think of this change now?

Thanks, I've now installed this on the master branch, with a few minor
followup changes in the documentation parts, and I'm closing this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.