This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Visibility of ELF symbols not taken into account by certain GDB commands?


On Fri, Feb 22, 2013 at 7:09 AM, Alfonso Acosta
<alfonso.acosta@gmail.com> wrote:
> Hi,
>
> I have observed that certain commands, ("print" and "info symbol" at
> least) pick only one symbol in case of multible definitions (e.g.
> malloc is defined in ls.so and libc.so, but only one of them is
> picked).
>
> During that selection, visibility is not taken into account (e.g. the
> ld.so malloc symbol is used although the globally visible one, from
> the dynamic loaders point of view, is the one in libc.so)
>
>
> Should this be considered a bug?
>
>
> At the very least, it seems very counterintuitive to me. I would had
> expected either using all occurrences of the symbol or picking the
> visible one.
>
> This issue is well covered by I question I made in Stackoverflow [1].
> Here is an example of what I mean:
>
> (gdb) info symbol malloc
> malloc in section .text of /lib64/ld-linux-x86-64.so.2
> (gdb) p malloc
> $1 = {void *(size_t)} 0x7ffff7df0930 <malloc>
> (gdb) info symbol 0x7ffff7df0930
> malloc in section .text of /lib64/ld-linux-x86-64.so.2
> (gdb) b malloc
> Breakpoint 2 at 0x7ffff7df0930: malloc. (2 locations)
> (gdb) info breakpoints
> Num     Type           Disp Enb Address            What
> 2       breakpoint     keep y   <MULTIPLE>
> 2.1                         y     0x00007ffff7df0930 in malloc at
> dl-minimal.c:95
> 2.2                         y     0x00007ffff7a9f9d0 in
> __GI___libc_malloc at malloc.c:2910
> (gdb)
>
>
> Thanks,
>
> Alfonso Acosta
>
>
> PS: I am running  "GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02".
>
> [1] http://stackoverflow.com/questions/14867024/duplicated-memory-management-symbols-in-libc-so-and-ld-linux-so/15008471#15008471

Hi.
Lots of things to consider here, and I may not cover everything in the
first pass.

In random order:

1) ELF symbol visibility doesn't really enter the picture.
Sometimes you don't want it to.  Though I can see a usefulness in
having knobs to control this, I'm not aware of any (could just be my
bad memory :-)) or any plans to add them.
[GDB needs to be file-format agnostic in general, but that doesn't
mean it can't provide file-format-specific features if they're useful
enough.]

1) The print command takes an expression.
While in theory one could have gdb do something like evaluate the
expression for all values of a name, I haven't seen any real need for
it.
What happens, in a nutshell, is gdb looks up the symbol in the current
context (whatever that is), and then does a search over all contexts.
This involves doing a linear search over the binary and all shared
libraries and using the first one found.  In this case it's the one in
ld.so.

That doesn't always find the copy one wants of course, and one TODO is
to support more expressiveness in specifying which version of a symbol
one wants.
Note that one thing you can (or rather should be able to) do today,
given that you know the source file, and that the source file names
are different, is things like

p 'malloc.c'::malloc
though I see that's busted.  Blech.

IWBN to be able to do things like p objfile::file::symbol.  RSN.
["objfile" is gdb parlance for the binary or a shared lib]

2) break works differently because it's easier to do, and more useful.
E.g., it's useful to set a breakpoint on all copies of static function
"foo" (or inlined function "foo"), setting aside shared libraries.

3) "info sym foo" takes an address, and an "address" is really just a
single entity.  The fact that "info sym malloc" works at all is
arguably just a convenience hack for the common case.
OTOH, "info addr foo" could print multiple results since in this case
"foo" is a symbol which can have multiple instances.
That would be a useful extension.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]