This enables LLD to relocate PC-relative R_PPC_REL32 and R_PPC_REL24 types (as used in bl instructions).
Diff Detail
Event Timeline
Ok, I've appended a simple test for REL24 in ppc-relocs.s:
.align 2 .section .R_PPC_REL24,"ax",@progbits .globl .FR_PPC_REL24 .FR_PPC_REL24: b .Lfoox .section .R_PPC_REL24_2,"ax",@progbits .Lfoox: # CHECK: Disassembly of section .R_PPC_REL24: # CHECK: .FR_PPC_REL24: # CHECK: 11014: 48 00 00 04 b .+4
That passes as expected, but I'm not sure how to emit a REL32 using assembler directives. I implemented REL32 because the .eh_frame section needs it when linking C++ (presumably to reference the functions being unwound).
If anyone knows how to do it with assembler directives or symbol variants, I'll write that test as well.
I'm not a PowerPC expert, but maybe something like this?
.global foo .section .R_PPC_REL32,"a" .quad foobar
That ends up emitting R_PPC_ADDR32 (absolute relocation, which also needs to be implemented).
I managed to get it emitting using CFI directives (i.e. .cfi_startproc and .cfi_endproc), but I'm not entirely certain now that particular relocation usage should function.
This adds a test for REL24.
REL32 conformance uncertain right now. Need assembler directive, or how to validate .cfi* directives that emit REL32.
Since ADDR32 was a trivial relocation for the last diff, this test is added to validate
Just to clarify, update diff to include *just* REL24/REL32, then submit ADDR32 standalone?
I mean I requested you submit the patch when I LGTMed, and then send me another patch to add ADDR32 support. (You usually want to submit a patch as soon as LGTMed and then make new features as new patches, instead of adding new code to an unsubmitted change. )
Ah, I was thinking that you had a commit access but for some reason didn't submit all these changes. I'll do that for you.