bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/14037] New: Bogus global symbol ABS redefinition when linking PI


From: bugdal at aerifal dot cx
Subject: [Bug ld/14037] New: Bogus global symbol ABS redefinition when linking PIC app to eh_frame-stripped shared library
Date: Tue, 01 May 2012 02:13:34 +0000

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

             Bug #: 14037
           Summary: Bogus global symbol ABS redefinition when linking PIC
                    app to eh_frame-stripped shared library
           Product: binutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
        AssignedTo: address@hidden
        ReportedBy: address@hidden
    Classification: Unclassified


When the following 3 conditions are satisfied:

1. Main program is built with -fPIC.
2. Main program uses global variables from the shared library.
3. Shared library has been stripped with the command:
strip --strip-unneeded -R .eh_frame -R .eh_frame_hdr

the GNU binutils linker generates incorrect symbol definitions for the affected
global variable. Instead of generating a copy relocation (which it would do for
non-PIC main program) or leaving the symbol undefined in the main program so
that both the main program and shared library's GOT entries for the variable
get resolved to the original copy of the variable in the shared library, it
generates a nonsensical ABSOLUTE symbol definition in the main program whose
value is the library-load-address-relative address of the variable in the
shared library. For example, instead of (readelf output for the application):

     5: 00000000     0 OBJECT  GLOBAL DEFAULT  UND global

we get:

     5: 000015f8     4 OBJECT  GLOBAL DEFAULT  ABS global

This in turn causes either the main app or the library to crash when trying to
access the global variable, since both GOT entries get resolved to this invalid
absolute address.

At least x86 and x86_64 are affected.

I encountered this issue when systems integrators using musl (my libc) were
trying to use the above strip command to debloat their libc file on disk. I
believe it's a valid optimization since musl does not use unwind tables
whatsoever, and in fact at first I suspected this was a bug on my side (in my
dynamic linker code perhaps), but I've created a minimal test case that
reproduces the issue with just binutils.

libfoo.c:

int global;
void setit(int x) { global = x; }

app.c:

void setit(int);
extern int global;
int main() { setit(42); return global; }

build:

gcc -fPIC -g libfoo.c -shared -o libfoo.so
strip -R .eh_frame -R .eh_frame_hdr libfoo.so
gcc -fPIC app.c -L. -lfoo

Compare results with and without the strip command to see the bug.

-- 
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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]