This is related to 21464, the original fix was not sufficient. Creating this binutils filing as a copy of the gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99783 From that bug: OK, I can reproduce, but I am not sure what is going on I will need to debug a bit more. This is what I have so far. ERROR: I am seeing the same error you report. buildroot/output/host/lib/gcc/or1k-buildroot-linux-uclibc/11.2.0/crtbeginS.o: in function `deregister_tm_clones': crtstuff.c:(.text+0x44): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_ITM_deregisterTMCloneTable' buildroot/output/host/lib/gcc/or1k-buildroot-linux-uclibc/11.2.0/crtbeginS.o: in function `register_tm_clones': crtstuff.c:(.text+0xcc): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_ITM_registerTMCloneTable' buildroot/output/host/lib/gcc/or1k-buildroot-linux-uclibc/11.2.0/crtbeginS.o: in function `__do_global_dtors_aux': crtstuff.c:(.text+0x12c): relocation truncated to fit: R_OR1K_GOT16 against symbol `__cxa_finalize' defined in .text section in buildroot/output/host/or1k-buildroot-linux-uclibc/sysroot/lib/libc.so.1 crtstuff.c:(.text+0x15c): relocation truncated to fit: R_OR1K_GOT16 against symbol `__deregister_frame_info@@GLIBC_2.0' defined in .text section in buildroot/output/host/lib/gcc/or1k-buildroot-linux-uclibc/11.2.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so buildroot/output/host/lib/gcc/or1k-buildroot-linux-uclibc/11.2.0/crtbeginS.o: in function `frame_dummy': Actual Code patterns: Looking at the generated object file. We can see R_OR1K_GOT_AHI16 followed by R_OR1K_GOT16. This confirms the cmodel=large is ON. or1k-elf-objdump -dr buildroot/output/host/lib/gcc/or1k-buildroot-linux-uclibc/11.2.0/crtbeginS.o deregister_tm_clones: 38: 1a 20 00 00 l.movhi r17,0x0 38: R_OR1K_GOT_AHI16 _ITM_deregisterTMCloneTable 3c: e2 31 98 00 l.add r17,r17,r19 40: 1a 60 00 00 l.movhi r19,0x0 44: 86 31 00 00 l.lwz r17,0(r17) 44: R_OR1K_GOT16 _ITM_deregisterTMCloneTable 48: e4 11 98 00 l.sfeq r17,r19 4c: 10 00 00 04 l.bf 5c <deregister_tm_clones+0x5c> 50: 85 21 00 00 l.lwz r9,0(r1) register_tm_clones: c0: 10 00 00 09 l.bf e4 <register_tm_clones+0x7c> c4: 1a 20 00 00 l.movhi r17,0x0 c4: R_OR1K_GOT_AHI16 _ITM_registerTMCloneTable c8: e2 31 98 00 l.add r17,r17,r19 cc: 86 31 00 00 l.lwz r17,0(r17) cc: R_OR1K_GOT16 _ITM_registerTMCloneTable d0: e4 11 a8 00 l.sfeq r17,r21 __do_global_dtors_aux: 150: 1a 20 00 00 l.movhi r17,0x0 150: R_OR1K_GOT_AHI16 __deregister_frame_info 154: e2 31 80 00 l.add r17,r17,r16 158: 1a 60 00 00 l.movhi r19,0x0 15c: 86 31 00 00 l.lwz r17,0(r17) 15c: R_OR1K_GOT16 __deregister_frame_info 160: e4 11 98 00 l.sfeq r17,r19 164: 10 00 00 07 l.bf 180 <__do_global_dtors_aux+0x90> IN buildroot/output/build/host-binutils-2.37/bfd/elf32-or1k.c: We have this bit of code which confirms we have the correct patches available in binutils. This code shows we should be avoiding this truncation if we have R_OR1K_GOT_AHI16 followed by R_OR1K_GOT16 which is what we have. Note, the comment above if (r_type == R_OR1K_GOT16 && saw_gotha) seems backwards. if (r_type == R_OR1K_GOT_AHI16) saw_gotha = true; /* If we have a R_OR1K_GOT16 followed by a R_OR1K_GOT_AHI16 relocation we assume the code is doing the right thing to avoid overflows. Here we mask the lower 16-bit of the relocation to avoid overflow validation failures. */ if (r_type == R_OR1K_GOT16 && saw_gotha) relocation &= 0xffff; I will have to look at this more.
The issue is the the relation has the 16-bit sign bit set. So even though we are masking out upper bits to try to avoid overflow we still get an error for signed overflow.
Posted patch: https://sourceware.org/pipermail/binutils/2022-January/119078.html
The master branch has been updated by Stafford Horne <shorne@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c7c6e55b60b072cdcc5c3fc27164b890a0f34520 commit c7c6e55b60b072cdcc5c3fc27164b890a0f34520 Author: Stafford Horne <shorne@gmail.com> Date: Wed Feb 2 20:11:56 2022 +0900 or1k: Avoid R_OR1K_GOT16 signed overflow by using special howto Previously when fixing PR 21464 we masked out upper bits of the relocation value in order to avoid overflow complaints when acceptable. It turns out this does not work when the relocation value ends up being signed. To fix this this patch introduces a special howto with complain_on_overflow set to complain_overflow_dont. This is used in place of the normal R_OR1K_GOT16 howto when we detect R_OR1K_GOT_AHI16 relocations. bfd/ChangeLog: PR 28735 * elf32-or1k.c (or1k_elf_got16_no_overflow_howto): Define. (or1k_elf_relocate_section): Use new howto instead of trying to mask out relocation bits.
This patch should fix it.