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

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

[Alfonso Acosta]

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

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

[Doug Evans]

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.

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

[Tom Tromey]

Alfonso> During that selection, visibility is not taken into account (e.g. the
Alfonso> ld.so malloc symbol is used although the globally visible one, from
Alfonso> the dynamic loaders point of view, is the one in libc.so)

Alfonso> Should this be considered a bug?

Doug> 1) ELF symbol visibility doesn't really enter the picture.
Doug> Sometimes you don't want it to.  Though I can see a usefulness in
Doug> having knobs to control this, I'm not aware of any (could just be my
Doug> bad memory :-)) or any plans to add them.

Yeah, I don't know about plans to deal with visibility, but there are
some open bugs about how gdb doesn't respect ELF semantics, and so you
can sometimes write expressions that don't give the same result as the
same expression in the source.

E.g., there's a couple of bugs related to copy relocations.

Doug> What happens, in a nutshell, is gdb looks up the symbol in the current
Doug> context (whatever that is), and then does a search over all contexts.
Doug> This involves doing a linear search over the binary and all shared
Doug> libraries and using the first one found.  In this case it's the one in
Doug> ld.so.

... there's also a tweak here to try to reproduce ELF semantics.  I
found elf_lookup_lib_symbol and the corresponding target_so_ops method,
but I thought there was some other hook too... can't find it right now.

Tom