https://sourceware.org/bugzilla/show_bug.cgi?id=22875
Bug ID: 22875 Summary: Strip complains about and then destroys unrecognised relocs Product: binutils Version: 2.31 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: nickc at redhat dot com Target Milestone: --- Hi Guys, If strip encounters a relocation that it does not recognise, it issues a warning message, and then proceeds to replace the relocation with a null version. It then completes successfully, even though it has now produced a corrupt binary. For example, consider this test: % cat unknown-reloc.s .text foo: .dc.l 0x12345678 .section .rela.text .dc.l 0 .dc.l 0 .dc.l 0x12345678 .dc.l 0 .dc.l 0 .dc.l 0 .dc.l 0 .dc.l 0 % as unknown-reloc.s -o unknown-reloc.o % readelf -r unknown-reloc.o Relocation section '.rela.text' at offset 0x44 contains 1 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 000012345678 unrecognized: 12345678 0 % strip -g unknown-reloc.o strip: bad-reloc.o: invalid relocation type 120 % echo $? 0 % readelf -r unknown-reloc.o Relocation section '.rela.text' at offset 0xc8 contains 1 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000000000 000000000000 R_X86_64_NONE 0 This is not just a theoretical problem. We (Red Hat) recently had a user report that they were seeing corrupt binaries, and the problem turned out to be that they were compiling using a toolchain with a 2.28 assembler that produced R_X86_64_REX_GOTPCRELX relocations, but using a version of strip that came from the 2.25 binutils release. There are at least two bugs here: * strip should not replace relocations that it does not recognise. * strip should either accept and ignore unknown relocations, or, if it must, complain about them, leave the input alone, and return an exit failure status. I am filing this bug as a reminder to myself to investigate and fix the problems. That is unless somebody else does it first... :-) Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils