https://sourceware.org/bugzilla/show_bug.cgi?id=32443
--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Fangrui Song from comment #12) > (In reply to H.J. Lu from comment #11) > > Created attachment 16093 [details] > > The final patch > > > > This is the final patch. > > This patch applies code transformatin for R_X86_64_PC32 , which is not the > right direction to pursue. > > https://inbox.sourceware.org/binutils/ > came9roo+lnbsiyzxtnfzw1d0tkzhwqs_bht6j4dmmmy8gxe...@mail.gmail.com/T/ > #m4a4b019ab4c35052531c7d92ae6a0af329cbf1bf > > R_X86_64_PC32 can be used in data directives where the transformation > is not feasible > > .data > .long .text -. # R_X86_64_PC32 > > Making relocation behavior depend on the SHF_EXECINSTR flag is > generally discouraged. (I have seen no example in the LLD codebase.) But rewriting opcode can depend on the SHF_EXECINSTR flag. I sent out the v4 patch to do that, plus checking MODRM for (%rip): https://sourceware.org/pipermail/binutils/2025-May/141221.html > For instructions, programmers may want to preserve the exact assembly > code they write. This could be for benchmarking specific instructions, > testing under an emulator, or ensuring a specific code pattern for OS > kernel diagnostics (e.g., Linux kernel's KCFI, which relies on a > specific trap code sequence). > > On this mailing list, RISC-V folks are introducing `.option exact` to > disable assembler/linker relaxation. > (https://sourceware.org/pipermail/binutils/2025-May/141075.html ) > > Referencing an SHN_ABS symbol in a C example does not provide > sufficient justification for implementing far-reaching retrofit > changes onto a widely used and well-established relocation type like > R_X86_64_PC32 . -- You are receiving this mail because: You are on the CC list for the bug.
