This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] [patch] 'info symbol' to print more info
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Michael Snyder <msnyder at vmware dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 14 Nov 2008 14:06:26 -0800
- Subject: Re: [RFA] [patch] 'info symbol' to print more info
- References: <20081114204617.A4A533A6B15@localhost> <491DF12A.5090903@vmware.com>
On Fri, Nov 14, 2008 at 1:44 PM, Michael Snyder <msnyder@vmware.com> wrote:
> Just one suggestion (and suggestion only) -- since the exec_file
> is sort of the default/common case, do you think it would be a
> good idea to check if it's the exec_file, and omit the objfile
> information if so?
I think there are two large classes of users:
- embedded people with no shared libraries and a single (statically
linked) executable, and
- everybody else.
I've never been in the first camp. From the second camp, if the
symbol is in the main executable, I want to know that too.
E.g. if I do 'info symbol &malloc', and it tells me .text in a.out,
that may well be a very important clue (that something unusual is
happening).
I do agree that for the fully-static executable case the extra
verbiage may be somewhat annoying. Looking for a way to tell if
that is the case ... Would the test below be sufficient?
if (ojbect_files->next)
/* there is only one object, so don't print its name ... */
I also just noticed inconsistency between 'info symbol' and
'maintenance translate-address' wording:
exit+0 section .text in /usr/lib64/libc.so.6
exit in section .text of /usr/lib64/libc.so.6
I'll fix that in the final patch so they are the same.
Thanks,
--
Paul Pluzhnikov