[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 --- Comment #2 from Fangrui Song --- (In reply to Palmer Dabbelt from comment #1) > Nelson and I are just chatting about this. It's not intentional, but we > also don't quite know what the right answer is here: there's some relocs we > can touch less (like leaving R_RISCV_ALIGN in outputs even after we've > aligned, for example) but others we'd have to avoid relaxing (like > R_RISCV_CALL, which requires two instructions). Certainly producing > binaries with R_RISCV_NONE is a bug, it's not even in the psABI so we can't > be producing binaries with it. > > So I think we're happy to fix bugs here, but we really need to know what the > desired output is. > > Do you have something more concrete about what you're looking for? Thanks for looking into this. My feeling is that --emit-relocs should switch to preserve the original relocation type, including R_RISCV_CALL_PLT(etc), R_RISCV_RELAX, and R_RISCV_ALIGN. Analysis tools can check whether R_RISCV_RELAX is present in a section. If present, they need to do disassembly work to figure out whether a R_RISCV_CALL_PLT relocations is associated with an un-relaxed code sequence of a relaxed code sequence. Yes, it may look dirty but I don't think there is a better way. (x86-32 relocation handling inspects the relocated relocation as well) FWIW I left a comment on https://lore.kernel.org/linux-riscv/2023091221.zejmknzcm5mwz...@google.com/T/#t on the only --emit-relocs use I can find, which is relatively new in the Linux kernel. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 Palmer Dabbelt changed: What|Removed |Added CC||palmer at gcc dot gnu.org --- Comment #1 from Palmer Dabbelt --- Nelson and I are just chatting about this. It's not intentional, but we also don't quite know what the right answer is here: there's some relocs we can touch less (like leaving R_RISCV_ALIGN in outputs even after we've aligned, for example) but others we'd have to avoid relaxing (like R_RISCV_CALL, which requires two instructions). Certainly producing binaries with R_RISCV_NONE is a bug, it's not even in the psABI so we can't be producing binaries with it. So I think we're happy to fix bugs here, but we really need to know what the desired output is. Do you have something more concrete about what you're looking for? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 Fangrui Song changed: What|Removed |Added CC||jnoorman at igalia dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 Fangrui Song changed: What|Removed |Added CC||jrtc27 at jrtc27 dot com, ||kito.cheng at gmail dot com, ||nelsonc1225 at sourceware dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30844] New: ld riscv: --emit-relocs does not retain the original relocation type
https://sourceware.org/bugzilla/show_bug.cgi?id=30844 Bug ID: 30844 Summary: ld riscv: --emit-relocs does not retain the original relocation type Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: i at maskray dot me Target Milestone: --- From https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation#ld---emit-relocs (with updated instructions) For GNU ld's AArch64/PPC64/x86-64 ports, the --emit-relocs code retains the original relocation type even if a linker optimization is applied. This is partly to communicate more information to the analysis tool and partly because the transformation may not be described with any existing relocation type. However, the RISC-V port changes the relocation type, including relocation types for relaxable instructions (e.g. R_RISCV_CALL_PLT), and markers (R_RISCV_ALIGN and R_RISCV_RELAX). I believe this was not a deliberate decision as there is no --emit-relocs test at all in ld/testsuite/ld-riscv-elf/. So far, the unintentional change seems fine but certain relaxations (such as TLSDESC) may not have relocation types associated with the relaxed instructions. cat > aarch64.s <<'eof' .global _start; _start: adrpx1, :got:x ldr x1, [x1, #:got_lo12:x] .data; .globl x; .hidden x; x: .word 0 eof cat > ppc64.s <<'eof' .globl _start; _start: addis 3, 2, .Lhidden@toc@ha ld3, .Lhidden@toc@l(3) lwa 3, 0(3) .data; .globl hidden; .hidden hidden; hidden: .long 0 .section .toc,"aw",@progbits .Lhidden: .tc hidden[TC], hidden eof cat > x86-64.s <<'eof' .globl _start; _start: movq foo@gotpcrel(%rip), %rax foo: nop eof aarch64-linux-gnu-gcc -fuse-ld=lld -B/tmp/Rel/bin -nostdlib aarch64.s -Wl,--emit-relocs -o aarch64 && aarch64-linux-gnu-objdump -dr aarch64 | sed -E '/^\s*$/d' powerpc64le-linux-gnu-gcc -nostdlib ppc64.s -Wl,--emit-relocs -o ppc64 && powerpc64le-linux-gnu-objdump -dr ppc64 | sed -E '/^\s*$/d' gcc -nostdlib x86-64.s -Wl,--emit-relocs -o x86-64 && objdump -dr x86-64 | sed -E '/^\s*$/d' cat > riscv64.s <<'eof' .global _start; _start: call f call f .balign 8 f: ret eof riscv64-linux-gnu-gcc -nostdlib riscv64.s -Wl,--emit-relocs -o riscv64 && riscv64-linux-gnu-objdump -dr riscv64 | sed -E '/^\s*$/d' Output (removed blank lines for compacter output): ``` aarch64: file format elf64-littleaarch64 Disassembly of section .text: 000102f8 <_start>: 102f8: d503201fnop 102f8: R_AARCH64_ADR_GOT_PAGE x 102fc: 10100661adr x1, 303c8 102fc: R_AARCH64_LD64_GOT_LO12_NC x ppc64: file format elf64-powerpcle Disassembly of section .text: 0240 <_start>: 240: 00 00 00 60 nop 240: R_PPC64_TOC16_HA hidden 244: 00 81 62 38 addir3,r2,-32512 244: R_PPC64_TOC16_LO hidden 248: 02 00 63 e8 lwa r3,0(r3) x86-64: file format elf64-x86-64 Disassembly of section .text: 12dd <_start>: 12dd: 48 8d 05 00 00 00 00lea0x0(%rip),%rax# 12e4 12e0: R_X86_64_REX_GOTPCRELXfoo-0x4 12e4 : 12e4: 90 nop riscv64: file format elf64-littleriscv Disassembly of section .text: 02a0 <_start>: 2a0: 008000efjal 2a8 2a0: R_RISCV_JALf 2a4: 004000efjal 2a8 2a4: R_RISCV_NONE *ABS*+0x4 2a4: R_RISCV_JALf 02a8 : 2a8: 8082ret 2a8: R_RISCV_NONE *ABS*+0x4 2a8: R_RISCV_NONE *ABS*+0x6 ``` I have a section "ld --emit-relocs" with very brief information on my website for a while. Recently https://reviews.llvm.org/D159082 motivated me to elaborate and bring this up:) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30703] bfd doc doesn't build anymore with makeinfo 4.12
https://sourceware.org/bugzilla/show_bug.cgi?id=30703 --- Comment #13 from vvinayag at arm dot com --- (In reply to Tom Tromey from comment #12) > (In reply to vvinayag from comment #11) > > (In reply to Tom Tromey from comment #10) > > > I backed out the offending patch. > > > > Is it possible to backport the revert to binutils-2_41-branch? We are using > > binutils-2_41-branch, and it is not building for the reasons mentioned > > above. > > I don't know binutils policy about this, but if it is OK, I can > do the work if needed. Who would be the best person to progress this? What could be the reason for not backporting it to binutils 2.41, which is where the issue was first introduced? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29759] [display html] Support for aarch64 is needed
https://sourceware.org/bugzilla/show_bug.cgi?id=29759 Ruud van der Pas changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #2 from Ruud van der Pas --- This one was accidentally closed and has to be reopened. -- You are receiving this mail because: You are on the CC list for the bug.
