This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
Protected function pointer doesn't work right. For pointer to protected function, gcc should treat it as if it is normal.
Created an attachment (id=7985) [edit] A testcase With the new linker, I got [hjl@gnu-20 x86_64-3]$ make gcc -fPIC -c -o x.o x.c gcc -shared -o libx.so x.o /usr/local/bin/ld: x.o: relocation R_X86_64_PC32 against `foo' can not be used when making a shared object; recompile with -fPIC /usr/local/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make: *** [libx.so] Error 1 With the old linker, I got [hjl@gnu-20 x86_64-3]$ make CC="gcc -B/usr/bin/" gcc -B/usr/bin/ -fPIC -c -o x.o x.c gcc -B/usr/bin/ -shared -o libx.so x.o gcc -B/usr/bin/ -o foo m.c libx.so -Wl,-rpath,. ./foo called from main foo_p: 0x400610 called from shared foo: 0x2a9566d8d8 shared foo: 0x2a9566d8d8 shared foo: 0x2a9566d8d8 called from shared foo_p: 0x400610 shared foo: 0x2a9566d8d8 shared foo: 0x2a9566d8d8 called from main foo: 0x400610 got from main foo: 0x2a9566d8d8 Function pointer `foo' are't the same in DSO and main
Isn't this just binutils ld/584? http://sources.redhat.com/bugzilla/show_bug.cgi?id=584 Alan M. claims this is a ld bug rather than a gcc bug.
The same bug also happen on i686-pc-linux-gnu: gcc -fPIC -c -o x.o x.c gcc -shared -o libx.so x.o gcc -o foo m.c libx.so -Wl,-rpath,. ./foo called from main foo_p: 0x80483e4 called from shared foo: 0x111524 shared foo: 0x111524 shared foo: 0x111524 called from shared foo_p: 0x80483e4 shared foo: 0x111524 shared foo: 0x111524 called from main foo: 0x80483e4 got from main foo: 0x111524 Function pointer `foo' are't the same in DSO and main
They aren't the same. It is function pointer vs. function. The other looks like a linker bug.
This is really a dup of bug 10908.
protected always binds local as you cannot override it so the bug is in the linker/asm. *** This bug has been marked as a duplicate of 10908 ***
Please take a closer look at the testcase. It is different from bug 10908. Basically, main executable and DSO see different function pointer values for the SAME function. From the linker /* Will references to this symbol always reference the symbol in this object? STV_PROTECTED is excluded from the visibility test here so that function pointer comparisons work properly. Since function symbols not defined in an app are set to their .plt entry, it's necessary for shared libs to also reference the .plt even though the symbol is really local to the shared lib. */ On many architectures, the function pointer != the address of the function body.
The difference between non protected and protected functions is the following in the asm: movl foo@GOT(%ebx), %eax leal foo@GOTOFF(%ebx), %eax but really add -fPIC to m.c make this work, so again this looks like an ld bug (maybe it is keeping the symbol protected or something). Or gcc is doing: cmpl $foo, -4(%ebp) which is not wrong in the non pic case.
So help out here, which is more correct the GOT or the GOTOFF?(In reply to comment #7) > Please take a closer look at the testcase. It is different from > bug 10908. Basically, main executable and DSO see different > function pointer values for the SAME function. From the linker That comment is only for the PPC bfd so it cannot apply to x86 :).
Well I think there is wrong reloc somewhere or a reloc being resolved wrongly because foo binds locally in x.c otherwise the protect is visibility is really useless otherwise (except maybe to make sure that it does not get overridden).
Depending on the psABI, because of copy relocation on data symbols and function pointer on function symbols, a protected symbol has to be treated very carefully. We have to check 2 things: 1. If the psABI uses copy relocation, protected data symbol is the same as normal symbol. 2. If the psABI doesn't support the "official function address", that is the psABI guarantee there is one and one only function address, only branch to functions can be treated as local.
Ignore the copy relocation. There is not much a compiler can do when the psABI doesn't support protected symbols with copy relocation. See: http://sources.redhat.com/ml/binutils/2003-03/msg00413.html
I think this bug report is reporting an actual bug. At least when using ELF, when the compiler takes the address of a protected function, it has to act as though it is taking the address of an ordinary function, and rely on the dynamic linker to do the right thing. If the compiler takes the address of a protected function without using the PLT, then as HJ says function symbols can not compare equal, even though they should. This is not something the linker can fix up. The dynamic linker, however, when setting up the PLT, should observe that the symbol is protected, and call the local symbol even if the executable overrides it. In other words, we should only treat protected function symbols as special when we call them. Otherwise they should be treated as ordinary symbols. This only applies to ELF. I don't know what should be done for other object file formats, if there are any others which support protected symbols.
A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01394.html
This is the updated patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01551.html This is the testcase patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01550.html
Confirming that the bug is real. I can't say I like HJ's solution though. It seems to require that ld.so resolve a protected symbol in a shared library to a symbol defined in the main app. That's weird. In other cases you don't want ld.so to do that, for instance when the main app defines a function with the same name as a protected library function. I think it might be difficult for ld.so to choose the right symbol, especially for the general case of multiple levels of shared libraries. Another problem is that making protected functions non-local prevents certain optimizations, for example see alias.c:mark_constant_function.
Please keep in mind that my proposal affects FUNCTION symbols only and my change won't change function CALL, which will still be local. It only changes the function pointer. BTW, I believe ld.so in the current glibc is OK. It is kind of tricky. I think I covered everything for FUNCTION symbols. If you believe ld.so is wrong in some cases, please send me a testcase. I will fix it.
I posted an updated patch http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00196.html I hope it will work better.
FWIW, the reason this leaves a bad taste in my mouth is that I strongly believe symbol visibility should be consistent between ELF platforms. There's at least one ELF platform where resolving a function pointer to a PLT entry is an absolute no-show (MIPS binding stubs).
Each psABI defines how function address works. Not all of psABIs have the same treatment for function address. Function address may mean different things for different psABIs. You can't even compare function address between the x86 psABI and the mips psABI. Where does the consistency come from?
(In reply to comment #18) > I posted an updated patch > > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00196.html > > I hope it will work better. Sorry to bother but where is the updated patch? That link leads to something else.
Is there any update on this bug? According to http://sourceware.org/ml/binutils/2005-01/msg00401.html, a protected function symbol cannot be used in a R_386_GOTOFF. I don't claim to understand the full implications of the issue, but it seems that the ld decision means gcc must not emit that relocation.