[llvm-bugs] [Bug 40004] New: llvm-objcopy should strip undefined symbols if they are no longer referenced following --only-section
via llvm-bugs
llvm-bugs at lists.llvm.org
Thu Dec 13 07:38:08 PST 2018
https://bugs.llvm.org/show_bug.cgi?id=40004
Bug ID: 40004
Summary: llvm-objcopy should strip undefined symbols if they
are no longer referenced following --only-section
Product: tools
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: llvm-objcopy
Assignee: unassignedbugs at nondot.org
Reporter: jh7370.2008 at my.bristol.ac.uk
CC: alexander.v.shaposhnikov at gmail.com,
jake.h.ehrlich at gmail.com,
jh7370.2008 at my.bristol.ac.uk,
llvm-bugs at lists.llvm.org, rupprecht at google.com
This may apply more widely when stripping specific sections, but I've not
tried. Currently, llvm-objcopy does not remove undefined symbols if the section
with the source of the reference (i.e. a relocation section) is stripped
following --only-section. This will make the object unusable for linking, even
though it probably should be usable under certain situations. It also is
different to what GNU objcopy does:
Input:
// bar.cpp
extern int bar;
int main(){
return bar;
}
Build with:
clang.exe --target=x86_64-pc-linux -c bar.cpp -g
GNU:
objcopy -j .debug_str bar.o foo.o
readelf foo.o -s
Symbol table '.symtab' contains 2 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 SECTION LOCAL DEFAULT 1
LLVM:
llvm-objcopy bar.o foo.o -j .debug_str
readelf -s foo.o
Symbol table '.symtab' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS bar.cpp
2: 0000000000000000 0 SECTION LOCAL DEFAULT 1
3: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND bar <-- BAD
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181213/5574b7b4/attachment.html>
More information about the llvm-bugs
mailing list