[ARM] Implement R_ARM_THM_PC8 relocation - #1776
[ARM] Implement R_ARM_THM_PC8 relocation#1776Deepak Shirke (deepakshirkem) wants to merge 1 commit into
Conversation
|
Deepak Shirke (@deepakshirkem) remember to update the docs when a new relocation is added. |
d4f7e0f to
9b2b8bb
Compare
| pReloc.issueUnsignedOverflow(pParent, val, 0, 0x3fc); | ||
| return ARMRelocator::Overflow; | ||
| } | ||
| if (val & 0x3) |
There was a problem hiding this comment.
Why is BadReloc returned here ? Do we have a test ?
There was a problem hiding this comment.
Why is BadReloc returned here ?
Shankar Easwaran (@quic-seaswara) BadReloc is returned when the offset is in range [0, 1023] but not 4-byte aligned. R_ARM_THM_PC8 encodes the offset as imm8 = val >> 2, so the offset must be 4-byte aligned to be encodeable. This matches LLD's behavior.
| .reloc 0, R_ARM_THM_PC8, low | ||
| // CHECK: Error: {{.*}}R_ARM_THM_PC8{{.*}}unaligned | ||
| .inst.n 0x49ff | ||
| .reloc 2, R_ARM_THM_PC8, unaligned |
There was a problem hiding this comment.
Do we have a test ?
Shankar Easwaran (Shankar Easwaran (@quic-seaswara)) Yes, This test verify that. unaligned symbol is at a non-4-byte-aligned offset and the linker correctly reports an error.
|
Shankar Easwaran (@quic-seaswara) Any feedback on this whenever you get time today? Thank you. |
Parth (parth-07)
left a comment
Parth (parth-07)
left a comment
There was a problem hiding this comment.
Can you please check why eld is reporting an error while resolving THM_PC8 relocation in this example?
#!/usr/bin/env bash
set -u
mkdir -p tmp
cat > tmp/thm_pc8_pa.s <<\EOF
.syntax unified
.thumb
.section .text.01,"ax",%progbits
.balign 4
.global _start
.thumb_func
_start:
.inst.n 0x48ff
.reloc 0, R_ARM_THM_PC8, target1
.inst.n 0x49ff
.reloc 2, R_ARM_THM_PC8, target2
.section .text.02,"ax",%progbits
.balign 4
.global target1
.type target1, %function
target1:
nop
bx lr
.section .text.03,"ax",%progbits
.balign 4
.space 1016
.global target2
.type target2, %function
target2:
nop
bx lr
EOF
cat > tmp/thm_pc8_pa.t <<\EOF
SECTIONS {
.text.01 0x1000 : { *(.text.01) }
.text.02 0x1004 : { *(.text.02) }
.text.03 0x1008 : { *(.text.03) }
}
EOF
llvm-mc --triple=thumbv6m-none-eabi --arm-add-build-attributes -filetype=obj -o tmp/thm_pc8_pa.o tmp/thm_pc8_pa.s
$LD -n --script tmp/thm_pc8_pa.t tmp/thm_pc8_pa.o -o tmp/thm_pc8_pa.out
llvm-readelf -x .text.01 tmp/thm_pc8_pa.out
9b2b8bb to
73fe399
Compare
Parth (@parth-07) Updated the patch. Can you run the test one more time? |
Parth (parth-07)
left a comment
Parth (parth-07)
left a comment
There was a problem hiding this comment.
Parth (@parth-07) Updated the patch. Can you run the test one more time?
Can you please briefly explain what was the issue?
Parth (@parth-07) The issue was that we were using P (raw instruction address) instead of Pa = (PC + 4) & ~3 as required by the ARM ABI for R_ARM_THM_PC8. The ARM ABI defines Pa as the instruction address aligned to the next 4-byte boundary, which accounts for the PC bias in Thumb mode. Using P directly caused incorrect offset calculations for symbols that are correctly in range. |
This is useful information. I believe that the PR description / commit-message still contains the outdated info. Can you please update them? |
R_ARM_THM_PC8 was previously unsupported. Implement the apply function using formula S + A - Pa per ARM IHI0044 where: - Pa = (PC + 4) & ~3 (instruction address aligned to 4-byte boundary) - Positive offset only, 10-bit range [0, 1023], 4-byte aligned - Encode result as imm8 = val >> 2 in bits[7:0] Note: Pa differs from P (raw instruction address) because Thumb PC8 relocations use the aligned PC value, not the raw instruction address. Signed-off-by: deepakshirkem <deepakshirke509@gmail.com>
73fe399 to
eb5b569
Compare
Parth (@parth-07) Done. Thank you. |
5 participants
Implement the
applyfunction forR_ARM_THM_PC8using the formulaS + A - Paper ARM IHI0044, where:Pa = (PC + 4) & ~3— the instruction address aligned to the next4-byte boundary (not the raw instruction address
P)imm8 = val >> 2in bits[7:0] of the 16-bitThumb instruction
Note: Using
Painstead ofPis important because Thumb PC8 relocations use the aligned PC value. Using the raw instruction address causes incorrect offset calculations for symbols that are correctly in range.Fixes #1337
CC: Steven Ramirez Rosa (@Steven6798)