[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