[llvm-jitlink] Support plain AArch32 range extension stubs in jitlink-check's stub_addr() expressions #73268
Conversation
…check's stub_addr() expressions
| @@ -12,6 +12,7 @@ | |||
|
|
|||
| #include "llvm-jitlink.h" | |||
|
|
|||
| #include "llvm/ExecutionEngine/Orc/Core.h" | |||
There was a problem hiding this comment.
Thanks, yes it's a leftover. Together with the orc::ExecutionSession &ES parameter below...
There was a problem hiding this comment.
We might play with section name here, in the future possibly.
There was a problem hiding this comment.
Well, ideally I'd like to have jitlink-check lines like this:
# jitlink-check: decode_operand(stub_addr(elf_stubs.o, fn) + 0, 1) = (fn & 0x0000ffff)
# jitlink-check: decode_operand(stub_addr(elf_stubs.o, fn) + 4, 2) = (fn & 0xffff0000) >> 16
We know it's a Thumv7 stub and we could check the movw + movt immediates directly, but decode_operand() doesn't support address expressions right now. We could add that, but it doesn't seem trivial.
One alternative might be to do it in the checker itself and then add something like:
# jitlink-check: decode_stub_target(elf_stubs.o, fn) = fn
In this case the section name would determine the stub type for the checker. Not urgent yet, but something to think about.
There was a problem hiding this comment.
My understanding is that now in JITLink AArch32 we can have PLT and interworking/range-extension stubs in different sections so they are kept orthogonal features. Now the checker is also acknowledging this separation.
Yes, I should express that in the commit message. Thanks for your notes!
There was a problem hiding this comment.
Well, ideally I'd like to have jitlink-check lines like this:
# jitlink-check: decode_operand(stub_addr(elf_stubs.o, fn) + 0, 1) = (fn & 0x0000ffff)
# jitlink-check: decode_operand(stub_addr(elf_stubs.o, fn) + 4, 2) = (fn & 0xffff0000) >> 16
We know it's a Thumv7 stub and we could check the movw + movt immediates directly, but decode_operand() doesn't support address expressions right now. We could add that, but it doesn't seem trivial.
One alternative might be to do it in the checker itself and then add something like:
# jitlink-check: decode_stub_target(elf_stubs.o, fn) = fn
In this case the section name would determine the stub type for the checker. Not urgent yet, but something to think about.
| @@ -12,6 +12,7 @@ | |||
|
|
|||
| #include "llvm-jitlink.h" | |||
|
|
|||
| #include "llvm/ExecutionEngine/Orc/Core.h" | |||
There was a problem hiding this comment.
Thanks, yes it's a leftover. Together with the orc::ExecutionSession &ES parameter below...
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
We want to use regular
stub_addr()expressions injitlink-checklines to test the generation of stubs in AArch32, but we don't want this to require a standardized GOT-based PLT implementation. In terms of performance and binary size it doesn't seem beneficial. And in terms of patching, we should be able to handle range-extension- and interworking-stubs without a lot of extra logic.This patch adds a separate path for AArch32 stubs in
llvm-jitlink-elfto allow it. The relocations in our stubs are not pointing to the GOT, but to the external symbol directly. Thus, we have to avoid access to the block of the edge target. Instead we only return the symbol name. This is enough to usestub_addr()expressions in tests.In order to allow decoding of stub target addresses in the future, we mention the stub flavor in the section name.