Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
This patch is a very reasonable one: it is a bit weird we can't expand la (under -fPIC) because R_RISCV_GOT_HI20 relocation does not have any associated syntax.
But I think we should go first to https://github.com/riscv/riscv-elf-psabi-doc (or the relevant forum) and suggest this new syntax before commiting this.
What do you think?
@rogfer01: James did actually get a patch for this committed to riscv-asm-manual https://github.com/riscv/riscv-asm-manual/blob/master/riscv-asm.md
Yeah, upstream suggested axing the list of assembly operators from the psABI doc as it's unnecessary duplication that gets out of date. Volunteers?...
I deliberately didn't include any expansion of la as the two can be done independently. I do however intend to submit a patch for it as well over the next few days, which shouldn't prove too problematic for D50496 as it already needs modifying and rebasing.
Yeah, upstream suggested axing the list of assembly operators from the psABI doc as it's unnecessary duplication that gets out of date. Volunteers?...
I may give it a shot then. At least a pointer to the asm manual will avoid confusions like mine in the future.
I deliberately didn't include any expansion of la as the two can be done independently. I do however intend to submit a patch for it as well over the next few days, which shouldn't prove too problematic for D50496 as it already needs modifying and rebasing.
Thanks a lot for working on this!
Could you correct the error message for InvalidUImm20AUIPC in RISCVAsmParser to include this new operator & change rv32i-invalid.s appropriately? When I did this I also added a test line in rv32i-valid.s but it's mostly testing the same thing as the test in relocations.s. Maybe you want to add that as well for completeness though.
I realise now this is also dependent on D54029, otherwise the corresponding %pcrel_lo gets evaluated to the offset of the auipc. I'll rebase on top of that.
Rebased on top of D54029, added test case to ensure R_RISCV_GOT_HI20 is always preserved for the linker and updated error message for InvalidUImm20AUIPC.
Do you need to add a check for RISCV::fixup_riscv_pcrel_hi20 in getPcRelHiExpr? Currently this is returning null and causing a segfault when running your relocations.s tests.
Yes, getPCRelHiExpr from D54029 needs to modified to also look for fixup_riscv_got_hi20, and if it does find one it should just force a relocation.
Slight annoying bit of churn turning getPCRelHiExpr into getPCRelHiFixup (when I tweaked D54029 I simply didn't make shouldForceRelocation give an error for a null getPCRelHiExpr return value, and therefore it could remain unchanged, but with the increased error checking we now need to get the entire MCFixup back).
Hi James, can you please rebase and confirm that you are aware of the new license put in place last Friday and intend to contribute under it. See http://lists.llvm.org/pipermail/llvm-dev/2019-January/129344.html https://llvm.org/docs/DeveloperPolicy.html#new-llvm-project-license-framework
Hi Alex, yes, I'm happy contributing under the new license (and filled out the relicensing form a few weeks ago too).
Thanks, this looks good to me (see small nit in comment). Do you need me to commit?
lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp | ||
---|---|---|
194 ↗ | (On Diff #185316) | Given that we expect a relocation will always be emitted, perhaps we should add instead: case RISCV::fixup_riscv_got_hi20: llvm_unreachable("Relocation should have been forced for fixup") |