Bug 9829 - add switch/param to make bt/backtrace print name of binary for each frame
Summary: add switch/param to make bt/backtrace print name of binary for each frame
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: backtrace (show other bugs)
Version: unknown
: P2 enhancement
Target Milestone: 6.8
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2009-02-09 13:12 UTC by mnemo
Modified: 2013-02-01 20:49 UTC (History)
2 users (show)

See Also:
Last reconfirmed: 2013-02-01 00:00:00

patch that makes gdb always print the binary for each function (582 bytes, patch)
2009-02-09 15:05 UTC, mnemo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mnemo 2009-02-09 13:12:49 UTC
When there is no symbols gdb prints backtraces as "f() in blah.so" for exported
symbols and "?? in blah.so" for non-exported symbols (I think).
Anyway, once I have symbols it instead prints "f() at utils.c:42" which is
great, however, often I still want the name of the binary that holds this function.

A pretty common use case for me is to find a SEGV in some random complex program
on Ubuntu (a program that I use a lot but that I don't do development on) and I
run it in gdb and I find a backtrace that runs through several libraries. For
example, "evolution" calling into "libmailstuff" which calls into "glib". Often
I can guess where the bug is based on the backtrace (for example I know the bug
is probably not in malloc() inside glibc and usually not in glib either).

So basically my next step is to look at the code for the function above malloc()
or whatever in the backtrace. Suppose the frame I find interesting is inside a
library which has symbols installed so it's is printed like this "f() at
utils.c:42". Now I have no way of knowing what package I should "apt-get source
PKG" to find the yadayada.c file.

If gdb instead printed "f() at utils.c:42 from some_binary.so" then I
could just do "dpkg -S some_binary.so" and quickly I would directly know
where to continue my investigation.

Basically I think there is an implicit assumption that gdb is only used to debug
programs that you wrote yourself (and hence you'd know what libraries are linked
and which functions goes into what library etc) but honestly I think gdb is
being used a lot today by people who don't really have this type of info. In
particular all the automatic crash reports in ubuntu have stacks generated by
gdb and the people triaging these bugs almost certain don't have detailed info
about each program bugs are found inside.

So, please can you add some switch/parameter to the "bt" command so
that it also prints the name of the binary?
Comment 1 mnemo 2009-02-09 15:05:54 UTC
Created attachment 3727 [details]
patch that makes gdb always print the binary for each function

I found that it's sufficient to just remove the following if-statement from
gdb/stack.c:729 to make gdb do what I'm talking about. This is the if

if (!funname || (!sal.symtab || !sal.symtab->filename))

Granted, this does not add a parameter to "bt" it just changes the default
behavior. At least I hope this patch can serve as a starting point.

Note: The condition "(!sal.symtab || !sal.symtab->filename)" is the logical
opposite (according to de morgan's law) to "sal.symtab && sal.symtab->filename"
which should explain why it's okay to drop the !funname part.
Comment 2 Tom Tromey 2013-02-01 20:49:46 UTC
I think having this as an optional feature would be good.

Maybe we could go a bit farther and let the user specify
some kind of format string that would be used when
printing frames in "bt".