I have implemented serveral relocation types with a test case (for R_AARCH64_ADR_PREL_PG_HI21 and R_AARCH64_ADD_ABS_LO12_NC). But it's a bit buggy that for
the R_AARCH64_ADR_PREL_PG_HI21_NC, it seems that it always fall into OutOfRangeError, my logic should be correct accroding to the specification of ARM. Therefore,
I would like to ask for a review and gain some insights for debugging the code.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Hi Kelvin, thanks for working on this. I will run your patch through my pi tonight and see how I can help.
it always fall into OutOfRangeError
I just fixed that with cdb335ffaff2. The issue didn't show up earlier, because the shift value was always smaller 32. I guess you want to either rebase on this commit or cherry-pick it to your development branch. Also, it would be good to do the same for your extractBit function.
Apart from that, I see two relocations in your test case, both for g: R_AARCH64_ADD_ABS_LO12_NC (offset 0x4) and R_AARCH64_ADD_ABS_LO12_NC (offset 0x8). Is this looking correct?
Eventually, your test still fails, because it has no CHECK lines. See inline comment.
llvm/test/ExecutionEngine/JITLink/AArch64/ELF_aarch64_test1.s | ||
---|---|---|
3 | My initial recommendation to use FileCheck was not good. JITLink tests actually use jitlink-check, which accepts some limited expressions to aid validation. I have to look up the details again as well. Maybe this example can give you some idea how it works: https://reviews.llvm.org/D90331#change-XdnNV6F7d9o7 |
llvm/lib/ExecutionEngine/JITLink/ELF_aarch64.cpp | ||
---|---|---|
103–105 | Do we have any existing bit-slicing utilities like this? It feels like we should, but I don't actually recall seeing them anywhere, and I don't think I've used anything like them in the MachO implementation. It would be good to check. If there are existing ones we should use them. If there aren't then we should aim to move these into a place where they can be re-used (that can be done separately from this patch). | |
107–109 | Are arm64 pages always 4k on Linux? On Darwin they're 16k. | |
111–113 | This should be moved into the aarch64.h header and renamed isInRangeForImmSN for consistency with the existing x86_64 functions. | |
llvm/test/ExecutionEngine/JITLink/AArch64/ELF_aarch64_test1.s | ||
3 | There isn't any good documentation. There is a comment describing the language at https://github.com/llvm/llvm-project/blob/d1fdd745d510f40d8741d44ce39f5ae24ee7f91a/llvm/include/llvm/ExecutionEngine/RuntimeDyldChecker.h#L32 Usually the best thing to do is look for a comparable existing test. In this case the best one would be the MachO / arm64 test case: | |
11–21 | I see a test for R_AARCH64_ADD_ABS_LO12_NC here, but not the other relocations -- it would be good to add tests for all of them. The tests don't execute so the loads/stores/arithmetic can usually be omitted, and only the instructions that actually have relocations attached included. |
llvm/lib/ExecutionEngine/JITLink/ELF_aarch64.cpp | ||
---|---|---|
103–105 | Not that I am aware of. Agree to put a little more effort into it. In fact, for range checks, both RuntimeDyld and LLD make frequent use of SignExtend64 from llvm/Support/MathExtras.h. Looking at the LLD code, it mostly uses raw shifts and typically it won't extract bits. Instead it tends to keep existing bits untouched and just overwrites the ones it needs to modify. I think this approach would work here as well. If so, we probably should get rid of extractBit altogether. | |
107–109 | Can we access the actual page size reported from the executor? ExecutorProcessControl has it and we could make it accessible from here either via JITLinkContext or JITLinkMemoryManager. Both appear out of scope for this patch, but we should at least add a FIXME here. | |
111–113 | Yes it has been part of my initial patch. I will move it as suggested or remove it if we go the SignExtend way. |
Do we have any existing bit-slicing utilities like this? It feels like we should, but I don't actually recall seeing them anywhere, and I don't think I've used anything like them in the MachO implementation.
It would be good to check. If there are existing ones we should use them. If there aren't then we should aim to move these into a place where they can be re-used (that can be done separately from this patch).