https://sourceware.org/bugzilla/show_bug.cgi?id=32443
--- Comment #12 from Fangrui Song <i at maskray dot me> --- (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.) 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.
