[Bug libc/12939] New: resolving shared library symbols returns wrong file

[Bug libc/12939] New: resolving shared library symbols returns wrong file

[andi-bz at firstfloor dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12939

           Summary: resolving shared library symbols returns wrong file
           Product: glibc
           Version: 2.14
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: andi-bz@firstfloor.org


dladdr() when called with a shared library symbol like printf
returns the name of the main executable in dli_fname

I suspect it happens because it resolves the PLT, but that's clearly
unexpected and makes it hard to use if you want to know
what .so printf is in. Is there a way around it?

Maybe the function could check for PLTs and resolve them?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug ld.so|libdl/12939] resolving shared library symbols returns wrong file

[jsm28 at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12939

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |ld.so|libdl

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/12939] resolving shared library symbols returns wrong file

[schwab@linux-m68k.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12939

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|drepper.fsp at gmail dot    |unassigned at sourceware
                   |com                         |dot org

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug dynamic-link/12939] resolving shared library symbols returns wrong file

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12939

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/12939] resolving shared library symbols returns wrong file

[alexander.long91 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12939

Alex Long <alexander.long91 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexander.long91 at gmail dot com

--- Comment #1 from Alex Long <alexander.long91 at gmail dot com> ---
Created attachment 7675
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7675&action=edit
dladdr arm vs x86_64 different behavior example

compiled with
g++ main.cpp -o main -Wall -Wextra -ldl -fPIC

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/12939] resolving shared library symbols returns wrong file

[alexander.long91 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12939

--- Comment #2 from Alex Long <alexander.long91 at gmail dot com> ---
As suggested in the dladdr() man-page, compiling your code to be position
independent, using -fPIC for example, may cause dladdr to return the path to
the shared library the symbol comes from rather than return the path to the
executable. 

However, one issue with this that I've noticed is that when building on or
cross-compiling for armv7l, dladdr will always return the path to the
executable for exported symbols that also happen to be called within the
program.

When compiled with 
/usr/bin/g++-4.7 main.cpp -o main-ARM -Wall -Wextra -ldl -fPIC

the attached example program prints
"printf comes from /lib/x86_64-linux-gnu/libc.so.6" on x86_64 machines
and
"printf comes from ./main" on armv7l

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/12939] resolving shared library symbols returns wrong file

[p.kopyl at samsung dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12939

Pavel Kopyl <p.kopyl at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |p.kopyl at samsung dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.