| Message ID | D0BDCAAE-AA06-465A-AF28-C5DA78080246@comcast.net |
|---|---|
| State | New |
| Headers | show |
>>>>> "Mike" == Mike Stump <mikestump@comcast.net> writes:
Mike> Here is a little one to add support for __FUNCTION__ to gdb so that we
Mike> can debug gcc…
Arguably this should be done in gdb.
Could you file a bug for that?
Tom
On Jun 5, 2013, at 10:17 AM, Tom Tromey <tromey@redhat.com> wrote: > Arguably this should be done in gdb. __FUNCTION__ is a private detail of gcc and a user of another compiler is free to define it in a way differently than gcc, and gdb shouldn't impinge that use... > Could you file a bug for that? I'd rather someone else do that, if they feel that is a good thing to do… I'm less sure about it. Let's copy the gdb list, so they can at least have visibility into it, and contemplate it. In gcc, we use the below definitions to hide some internal details of gcc and some internal details of a language standard that might be used in #defines that we might want to use at the gdb command prompt (with -g3), so those macros just-work. So, the open question is, would is be better for gcc to ensure this into the macro table in the debug output of a translation unit, or drop it in to gdb with the .gdbinit file, or would it be better for gdb to _fix_ it? # Define some macros helpful to gdb when it is expanding macros. macro define __FILE__ "gdb" macro define __LINE__ 1 macro define __FUNCTION__ "gdb" macro define __null 0
Index: gdbinit.in =================================================================== --- gdbinit.in (revision 199700) +++ gdbinit.in (working copy) @@ -184,6 +184,7 @@ end # Define some macros helpful to gdb when it is expanding macros. macro define __FILE__ "gdb" macro define __LINE__ 1 +macro define __FUNCTION__ "gdb" macro define __null 0 # Gracefully handle aborts in functions used from gdb.