Notices

1. Vertigo #$FF (vertigo@hackers.town)'s status on Wednesday, 05-May-2021 22:01:16 CEST Vertigo #$FF

   Calling all RISC-V developers using the GNU toolchain.

   I have some code like this in a foo.S file:

   .extern PGM_START # ...etc... la a2,PGM_START

   In the sections.lds linker script (passed via the riscv64-unknown-elf-ld -T flag), PGM_START is set to an address:

   PGM_START = 0x28000;

   When I assemble foo.S, I see it is expanded to something like this:

   ld a2,0x28 addi a2,a2,-8

   Where is this -8 offset coming from? This appears to be a failure of GNU ld to apply a relaxation. Except for manually replacing la with auipc, how can I convince ld that there is no -8 bias to that symbol?

   Boosts welcome. I'm desparate at this point.

   • Vertigo #$FF (vertigo@hackers.town)'s status on Wednesday, 05-May-2021 22:15:22 CEST Vertigo #$FF

     • Ekaitz Zárraga 👹

     @ekaitz_zarraga I'm relocating a chunk of ROM code into RAM (think, memcpy(rom_start, 0x28000, 0x8000) in C). It's a 32-bit processor, so no double-words. But, even if I just comment out the copy loop, the -8 bias remains. It makes no sense.

   • Vertigo #$FF (vertigo@hackers.town)'s status on Wednesday, 05-May-2021 22:18:34 CEST Vertigo #$FF

     • Ekaitz Zárraga 👹

     @ekaitz_zarraga If you pass -march=rv32i it will assemble for RV32. There are similar flags for ld.

   • Vertigo #$FF (vertigo@hackers.town)'s status on Wednesday, 05-May-2021 22:19:52 CEST Vertigo #$FF

     • Ekaitz Zárraga 👹

     @ekaitz_zarraga Sorry; that needs to be auipc, not ld.

   • Vertigo #$FF (vertigo@hackers.town)'s status on Wednesday, 05-May-2021 22:36:13 CEST Vertigo #$FF

     • Ekaitz Zárraga 👹

     @ekaitz_zarraga So, here's the thing.

     If I come up with a simpler example, the bias changes. Or the linker does something different altogether. This is a bug which seems extremely sensitive to input conditions.

     Here's a more complete replica of the code:

     .text.globl _start.extern _IMG_START.extern _IMG_END.extern _PGM_START.type _start,@function_start: la a0,_IMG_START la a1,_IMG_END la a2,_PGM_START1: lw a4,0(a0) sw a4,0(a2) addi a0,a0,4 addi a2,a2,4 bne a0,a1,1b j _PGM_START.size _start, .-_start
   • Vertigo #$FF (vertigo@hackers.town)'s status on Wednesday, 05-May-2021 22:40:31 CEST Vertigo #$FF

     • Ekaitz Zárraga 👹

     @ekaitz_zarraga

     la a2,_PGM_START # = 0x28000

     should expand to:

     auipc a2,0x28

     Instead, it expands to:

     auipc a2,0x28addi a2,a2,-8

     That's the wrong address. If this code is executed, the copy loop will use the wrong target address (it'll be off by 8 bytes in this case).

   • Vertigo #$FF (vertigo@hackers.town)'s status on Wednesday, 05-May-2021 23:42:29 CEST Vertigo #$FF

     • Ekaitz Zárraga 👹

     @ekaitz_zarraga OMG.

     OMG. Are you ready for this?

     I can't stop laughing at this. I goofed hard.

     The AUIPC instruction adds the value 0x28000+PC of the instruction, which in this case, happens to be at address 0x00008. So, A2 is loaded with 0x280008.

     So the ADDI A2,A2,-8 instruction adjusts that to point A2 back at the desired value.

     I'm still baffled why it didn't just use LUI in that case, but it at least does arrive at the right answer. It had me confused since this morning.