[llvm] [AVR] Fix parsing & emitting relative jumps (PR #102936)
via llvm-commits
llvm-commits at lists.llvm.org
Fri Aug 30 04:48:10 PDT 2024
aykevl wrote:
I'm mainly in favor of merging any reasonable fix in time for the LLVM 19 deadline (coming Tuesday) so that the AVR won't be totally broken in there. Whichever fix it is, I'm less concerned about. The PR as-is seems reasonable to me.
> I'm leaning towards resolving the relocations, because the current behavior seems to confuse people:
I'm not sure I agree with "it confuses people". Yes, it may confuse people, but that's just how relocations work.
For example, if I have this code:
```c++
void foo(void);
void bar(void) {
foo();
}
```
and I compile it to an ARM object file, I get the following:
```
$ llvm-objdump -d tmp/test.o
[...]
00000000 <bar>:
0: b580 push {r7, lr}
2: af00 add r7, sp, #0x0
4: f7ff fffe bl 0x4 <bar+0x4> @ imm = #-0x4
8: bd80 pop {r7, pc}
```
The same issue is present here: the `bl` appears to jump to itself.
It's only when you show relocations, that you see that it's actually a call to `foo`:
```
$ llvm-objdump -dr tmp/test.o
[...]
00000000 <bar>:
0: b580 push {r7, lr}
2: af00 add r7, sp, #0x0
4: f7ff fffe bl 0x4 <bar+0x4> @ imm = #-0x4
00000004: R_ARM_THM_CALL foo
8: bd80 pop {r7, pc}
```
@MaskRay also has a good explanation here: https://github.com/llvm/llvm-project/issues/104853#issuecomment-2303564498
We could also do both and have all branches point to the destination, _and_ insert relocations.
Anyway, I hope this doesn't distract too much. I just hope we can get a fix in for LLVM 19 because having _working_ code is better than having a totally broken AVR backend. We can think of the most proper fix afterwards.
https://github.com/llvm/llvm-project/pull/102936
More information about the llvm-commits
mailing list