Hello, On Thu, 16 Jul 2020, Herman ten Brugge via Tinycc-devel wrote:
While testing gmp on the x86_64 target I discovered a fuction pointer bug. (reuse in directory tests/mpf) The code: #include <stdio.h> typedef int (*func) (int); func allfunc[] = { putchar }; int main(void) { printf ("%d\n", allfunc[0] == putchar); return 0; }prints 0 on x86_64, macos and riscv (all other targets (i386, arm, arm64, win32, win64) print 1).There seems to be something wrong with relocation. The allfunc[0] points to the got table. The putchar to the externel symbol.
Yeah, known problem. Function pointer value comparisons involving functions in other shared objects are surprisingly complicated when shared objects and lazy linking (and hence PLT slots) are involved. It took many years to fix most (or all?) corners cases even in binutils and gcc, and some even can't be fixed when weak or protected symbols are involved.
In this particular case the reason is that TCCs linker doesn't currently emit outstanding relocations for executables except for the GOT, so the reference to putchar in the data section (in allfunc) has to be statically resolved to something local, and that's the PLT slot.
Note that this only affects the value of the function pointer itself, not the semantics (i.e. you can call through allfunc[0] just fine), so it's relatively seldomly a real problem. Does this affect anything else than a synthetic test case in gmp?
Ciao, Michael.
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
