This is a 31bits relative relocation instead of a 32bits absolute relocation.
Details
Diff Detail
Event Timeline
Your solution is the same way that R_ARM_PREL31 is handled in lld, so this looks fine from a correctness point of view.
I'm not familiar with this area so I think you'll need approval from a maintainer, they may also insist on a test being written.
Your solution is the same way that R_ARM_PREL31 is handled in lld, so this looks fine from a correctness point of view.
Good to know.... Would have saved me some time....
they may also insist on a test being written.
The failure shows up as invalid unwind info. Any pointer to a similar test / how can I write one?
Apologies I'm not familiar with mcjit to know how to write a test for this. Speculating:
- To get a prel31 relocation that will fail there will need to be a negative offset. If the .arm.exidx section is after the executable code or any link to a .ARM.extab section in memory/file the offsets will be negative will show up problems.
- If there is anyway to test the top-bit of the relocated entry you should be able to detect it.
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp | ||
---|---|---|
468 | I think I made a stupid mistake here... Should be 0x80000000 instead of 0x8000000 (7 zeros instead of 6 ......) Will update later. |
This looks good to me from an ARM perspective. I'm not a contributor in this area so you may want to wait a bit to see if anyone objects on style grounds.
Ping. Does this still need more review or is this OK to merge? I'll also need someone else to push for me since I don't have commit access.
I think I made a stupid mistake here... Should be 0x80000000 instead of 0x8000000 (7 zeros instead of 6 ......) Will update later.