Bug 4716 - --strip-unneeded strips too much with relocatable ELF objects from fpc/nasm
Summary: --strip-unneeded strips too much with relocatable ELF objects from fpc/nasm
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.18
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
: 17832 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-06-30 14:24 UTC by Mike Frysinger
Modified: 2015-01-20 18:59 UTC (History)
3 users (show)

See Also:
Host: i686-linux-gnu
Target:
Build:
Last reconfirmed:


Attachments
syscall.o object from fpc (256 bytes, application/octet-stream)
2007-06-30 14:25 UTC, Mike Frysinger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Frysinger 2007-06-30 14:24:04 UTC
relocatable ELF objects generated by fpc (the free pascal compiler) dont seem to
play well with `strip --strip-unneeded` ... i'm wondering if this is a bug in
strip or in fpc (it not generating enough ELF information), but i think it's a
bug in strip ;)

for example, in the attached object produced by fpc, there is a global symbol
THREADVARLIST_SYSCALL which is culled after being processed with --strip-unneeded

similar behavior can be seen with yasm/nasm when generating objects without
DWARF debug code ... for example:
$ cat test.asm
GLOBAL _foo:function
_foo:
	ret;
$ yasm -f elf test.asm -o test.o
$ readelf -s test.o | grep foo
     3: 00000000     0 FUNC    GLOBAL DEFAULT    4 _foo
$ strip --strip-unneeded test.o
$ readelf -s test.o | grep foo
<nothing>
$ yasm -g dwarf2 -f elf test.asm -o test.o
$ readelf -s test.o | grep foo
     7: 00000000     0 FUNC    GLOBAL DEFAULT    4 _foo
$ strip --strip-unneeded test.o
$ readelf -s test.o | grep foo
     2: 00000000     0 FUNC    GLOBAL DEFAULT    1 _foo
Comment 1 Mike Frysinger 2007-06-30 14:25:46 UTC
Created attachment 1906 [details]
syscall.o object from fpc
Comment 2 Mike Frysinger 2007-06-30 14:33:36 UTC
binutils 2.16.1, 2.17, 2.17.50.0.17, and current CVS HEAD all exhibit the same
behavior for me
Comment 4 law 2015-01-20 18:59:48 UTC
*** Bug 17832 has been marked as a duplicate of this bug. ***