https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114158
Karl Mehltretter <kmehltretter at googlemail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmehltretter at googlemail dot
com
--- Comment #6 from Karl Mehltretter <kmehltretter at googlemail dot com> ---
Confirming the SH side, and that it is still present on trunk
(3f1743f5e, 2026-09-28: the __FDPIC__ branches in libgcc/crtstuff.c are
unchanged).
With a sh2eb-linux-muslfdpic GCC 11.2.1 built without musl-cross-make's
0008-fdpic-crtstuff-pr114158.diff (the musl.cc toolchain), crtbegin.o
and crtbeginS.o put code addresses in .init_array and .fini_array:
Relocation section '.rela.init_array' contains 1 entry:
00000000 00000201 R_SH_DIR32 00000000 .text + 0
while a user constructor in the same executable gets a function
descriptor, so one .init_array holds both kinds of entry:
0x10f14 R_SH_DIR32 .text + 0x228 (frame_dummy code)
0x10f18 R_SH_DIR32 .got + 0 (descriptor of the constructor)
On a J-Core J2 running Linux, every dynamically linked program built
this way branches from musl's do_init_fini() to 0xd0082f86 before
main(). 0xd008 0x2f86 are the first two opcodes of frame_dummy, read as
a descriptor. Linking without crtbegin/crtend makes the programs run.
Could the Target field include sh*-*-*fdpic?
