Summary: | Weak undefined symbol doesn't work properly with PIE | ||
---|---|---|---|
Product: | glibc | Reporter: | H.J. Lu <hjl.tools> |
Component: | libc | Assignee: | Ulrich Drepper <drepper.fsp> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | glibc-bugs, toolchain |
Priority: | P2 | Flags: | fweimer:
security-
|
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | ||
Bug Depends on: | 2218 | ||
Bug Blocks: | |||
Attachments: | A testcase |
Description
H.J. Lu
2006-01-31 19:13:28 UTC
Created attachment 854 [details]
A testcase
PIE built with the fixed linker, I got
gcc -B./ -c -fPIC -g bar.c
gcc -B./ -shared -o libbar.so bar.o #-z nocombreloc
gcc -B./ -c -fPIC -g foo.c
gcc -B./ -c -fPIC -g main.c
gcc -B./ -c -fPIC -g dummy.c
gcc -B./ -shared -o libdummy.so dummy.o #-z nocombreloc
gcc -B./ -pie -o pie foo.o main.o libdummy.so -Wl,-z,nocombreloc -Wl,-rpath,.
gcc -B./ -o exec foo.o main.o libdummy.so -Wl,-z,nocombreloc -Wl,-rpath,.
cp -af libbar.so libdummy.so
./exec
main
foo
PASSED
./pie
main
foo
FAILED
That is undefined weak symbol in PIE is resolved to a definition in
libdummy.so unlike the normal executable.
A patch is posted at http://sources.redhat.com/ml/libc-alpha/2006-01/msg00152.html I completely disagree. The main executable references undef_func. It's not available at link time. That's fine, it's a weak reference. Like every other weak reference every user has to check whether the pointer is NULL or not. But the fact that the symbol is not defined doesn't mean it should not be found at runtime. It should be treated like every other symbol not found in the executable itself (sans the error message from the linker). This means, the correct behavior is for the linker to emit a relocation for the symbol in which case the exec test case would also print FAILED. This is a bug in binutils. |