* Re: Visibility of ELF symbols not taken into account by certain GDB commands?
2013-02-22 15:10 Visibility of ELF symbols not taken into account by certain GDB commands? Alfonso Acosta
@ 2013-02-25 18:09 ` Doug Evans
2013-03-15 15:32 ` Tom Tromey
0 siblings, 1 reply; 3+ messages in thread
From: Doug Evans @ 2013-02-25 18:09 UTC (permalink / raw)
To: Alfonso Acosta; +Cc: gdb
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.
^ permalink raw reply [flat|nested] 3+ messages in thread