This is a trimmed-down version of gcc compiling itself with TEXTRELs on ia64: https://bugs.gentoo.org/566118 Minimal reproducer: // cat lto-lang.c struct a { int (*b)(void); int c; }; int d(void) {} const struct a e = { &d, 0, }; int main(){} $ LANG=C ia64-unknown-linux-gnu-gcc -O0 -no-pie -fno-PIE lto-lang.c -o lto-lang -Wl,-z,text -rdynamic /usr/libexec/gcc/ia64-unknown-linux-gnu/ld: read-only segment has dynamic relocations. collect2: error: ld returned 1 exit status Used version: binutils-2.30 (older 2.29 is also affected), gcc-HEAD (older 6.4.0 is also affected) I'm not sure who exactly is at fault here: gcc or binutils. What happens here is: 'const struct e' (with .text pointer) is placed into '.rodata' by gcc and later is merged into '.text'. What I suspect should happen: 'const struct e' (with .text pointer) is placed into '.data.rel.ro' by gcc and later is merged into '.data'?
This is a GCC bug. The function "d" here is non-static and thus exported as a dynamic symbol. On ia64, function descriptors for dynamic symbols are always allocated by the dynamic linker at runtime for canonicalisation (yes, there are other things you could do, but this is what was chosen), and therefore are not link-time constants, even though the contents of this function descriptor can be determined at link-time (since this is linking an executable). GCC should instead be placing this in a relro section like you said.
rdynamic is a linker option that the compiler ignores, except to pass on to the linker. As far as the compiler knows, you are building a non-pic application, and hence the symbol is local. We can't assume that -rdynamic will be used at compile time, and hence to make this work we must assume that any local symbol might become global at link time. We can fix this my modifying the ia64_reloc_rw_mask function to return 3 when non-pic, same as it does when pic, to indicate that local symbols with relocs aren't read-only. I don't have access to ia64 hardware, so I don't have any easy way to test this. The symbol ends up in .data.rel.ro.local instead of .data.rel.ro, but presumably that is OK.
Created attachment 43514 [details] untested patch
(In reply to Jim Wilson from comment #2) > rdynamic is a linker option that the compiler ignores, except to pass on to > the linker. As far as the compiler knows, you are building a non-pic > application, and hence the symbol is local. We can't assume that -rdynamic > will be used at compile time, and hence to make this work we must assume > that any local symbol might become global at link time. Ah I see, that explains it. > We can fix this my modifying the ia64_reloc_rw_mask function to return 3 > when non-pic, same as it does when pic, to indicate that local symbols with > relocs aren't read-only. > > I don't have access to ia64 hardware, so I don't have any easy way to test > this. > The symbol ends up in .data.rel.ro.local instead of .data.rel.ro, but > presumably that is OK. That's what happens on hppa which has similar function descriptor behaviour, so that should be fine.
I did not regression-test this patch on gcc testsuite but this patch fixes TEXTREL on gcc and still produces working glibc and kernel on ia64.
Gentoo runs the patch for a while system-wide and it seems to work fine. Worth submitting the patch for review?
I was ia64 maintainer when I wrote the patch, but couldn't test it. I'm not the ia64 maintainer anymore. I suggest asking the current ia64 maintainer. Though, oops, I see we don't have one listed in the MAINTAINER file. I thought we had appointed one. I'm a global maintainer, but that doesn't give me power to approve my own patch for things I don't maintain anymore. I'm hopelessly overcommitted on RISC-V issues so unlikely to have time to do anything here.