[Top][All Lists]
[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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug ld/14037] New: Bogus global symbol ABS redefinition when linking PIC app to eh_frame-stripped shared library,
bugdal at aerifal dot cx <=