[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.

[petemoore at gmx dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=27217

Pete Moore <petemoore at gmx dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |petemoore at gmx dot net

--- Comment #30 from Pete Moore <petemoore at gmx dot net> ---
I have a simple test case which I think is consistent with this bug:

```
$ cat adrp.s 
.global _start
_start: adrp x0, 0x8000
```

After assembling and linking:

```
$ aarch64-none-elf-as -o adrp.o adrp.s 
$ aarch64-none-elf-ld -Ttext=0x0 -o adrp.elf adrp.o
aarch64-none-elf-ld: adrp.o: in function `_start':
(.text+0x0): undefined reference to `no symbol'
```

Note, the following trick works (if e.g. _start is known to be 0):

```
$ cat adrp.s 
.global _start
_start: adrp x0, 0x8000 + _start
```

which assembles as desired:

```
$ aarch64-none-elf-objdump -d adrp.elf

adrp.elf:     file format elf64-littleaarch64


Disassembly of section .text:

0000000000000000 <_start>:
   0:   90000040        adrp    x0, 8000 <_start+0x8000>
```

However, this only works if _start is fixed and known. Being able to specify an
absolute (rather than relative) value for the immediate of the adrp instruction
is useful for e.g. referencing peripherals at fixed locations which are known
to be in the +/- 4GB range of the current address. My particular use case is
referencing Raspberry Pi peripheral base addresses.

Let me know if I should raise a separate bug, or if the above test case is is
consistent with the current bug. Many thanks!

```
$ aarch64-none-elf-ld --version
GNU ld (GNU Binutils) 2.39
```

-- 
You are receiving this mail because:
You are on the CC list for the bug.