Fwd: RISC-V bare-metal: GDB loses source line info when .text starts at 0x0

Fwd: RISC-V bare-metal: GDB loses source line info when .text starts at 0x0

[Zhao Yiming via Gdb]

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

Hi GDB maintainers,

I am seeing a possible GDB source-line lookup issue while remote-debugging a
bare-metal RISC-V ELF.

Environment:
- GDB: 15.2.90.20241210-git, Xuantie-900 elf newlib gcc Toolchain V3.2.0
B-20250627
- GCC: 14.1.1 20240710, same Xuantie toolchain
- ld: GNU ld 2.42.50
- QEMU: qemu-system-riscv64 8.2.94 (cskysim V5.2.8 B-20250721)
- Host: Windows 10.0.19045.6466

Build flags:

  -O0 -g -ffunction-sections -fdata-sections -Wl,--gc-sections

The failing ELF is linked as a bare-metal image with .text VMA = 0x0.

Reproducer outline:

  target remote :1234
  load
  b main
  c
  s
  s
  n
  n
  n
  n

After stepping out of SPI_ModifyGlobalReg(), GDB prints only:

  0x00000000000002dc in I2C_PinMuxSetup ()

Expected:

  I2C_PinMuxSetup (...) at ../src/demoI2c.c:36

The line information appears to exist:

  addr2line -e LRV4201_SPI_I2C_2.elf 0x2dc
  -> ../src/demoI2c.c:36

Relevant symbols:

  0000000000000000 T Reset_Handler
  00000000000002ca T I2C_PinMuxSetup
  0000000000000920 T SPI_ModifyGlobalReg

Additional observations:

1. If the linker script changes .text from 0x0 to a non-zero address, the
   GDB problem disappears.
2. If .text still starts at 0x0 but Reset_Handler is placed in .text instead
   of .text.init, the problem also disappears.
3. The failing ELF contains many zero-address decoded line-table rows from
   demoI2c.c/demoSpi.c. A no-gc build and a reduced working project do not.

I attached a small archive with decoded line tables, objdump section
headers,
addr2line output, build flags, linker script, and relevant sources. The full
ELFs are not attached because of the mailing list size limit, but I can
provide
them or file a Bugzilla issue if preferred.

Best regards,
Raymond

[-- Attachment #2: evidence_info.zip --]
[-- Type: application/zip, Size: 61589 bytes --]

Re: Fwd: RISC-V bare-metal: GDB loses source line info when .text starts at 0x0

[Andrew Burgess via Gdb]

Zhao Yiming via Gdb <gdb@sourceware.org> writes:

> Hi GDB maintainers,
>
> I am seeing a possible GDB source-line lookup issue while remote-debugging a
> bare-metal RISC-V ELF.
>
> Environment:
> - GDB: 15.2.90.20241210-git, Xuantie-900 elf newlib gcc Toolchain V3.2.0
> B-20250627
> - GCC: 14.1.1 20240710, same Xuantie toolchain
> - ld: GNU ld 2.42.50
> - QEMU: qemu-system-riscv64 8.2.94 (cskysim V5.2.8 B-20250721)
> - Host: Windows 10.0.19045.6466
>
> Build flags:
>
>   -O0 -g -ffunction-sections -fdata-sections -Wl,--gc-sections
>
> The failing ELF is linked as a bare-metal image with .text VMA = 0x0.
>
> Reproducer outline:
>
>   target remote :1234
>   load
>   b main
>   c
>   s
>   s
>   n
>   n
>   n
>   n
>
> After stepping out of SPI_ModifyGlobalReg(), GDB prints only:
>
>   0x00000000000002dc in I2C_PinMuxSetup ()
>
> Expected:
>
>   I2C_PinMuxSetup (...) at ../src/demoI2c.c:36
>
> The line information appears to exist:
>
>   addr2line -e LRV4201_SPI_I2C_2.elf 0x2dc
>   -> ../src/demoI2c.c:36
>
> Relevant symbols:
>
>   0000000000000000 T Reset_Handler
>   00000000000002ca T I2C_PinMuxSetup
>   0000000000000920 T SPI_ModifyGlobalReg
>
> Additional observations:
>
> 1. If the linker script changes .text from 0x0 to a non-zero address, the
>    GDB problem disappears.
> 2. If .text still starts at 0x0 but Reset_Handler is placed in .text instead
>    of .text.init, the problem also disappears.
> 3. The failing ELF contains many zero-address decoded line-table rows from
>    demoI2c.c/demoSpi.c. A no-gc build and a reduced working project do not.
>
> I attached a small archive with decoded line tables, objdump section
> headers,
> addr2line output, build flags, linker script, and relevant sources. The full
> ELFs are not attached because of the mailing list size limit, but I can
> provide
> them or file a Bugzilla issue if preferred.
>

If you could file a bugzilla, include this description, and attach
everything including the ELFs, that would make things easier.  If you
post the link I'll try to take a look when I have time.

I'm not surprised that there are issues here, some of the older GDB code
still makes use of 0 as a "magic" flag indicating no-data, etc.  I've
worked on targets that allow code to be placed at address 0, and fixed
some of these issues in the past, so it would be nice to fix this one
too.

Thanks,
Andrew

Re: Fwd: RISC-V bare-metal: GDB loses source line info when .text starts at 0x0

[Andrew Burgess via Gdb]

Andrew Burgess <aburgess@redhat.com> writes:

> Zhao Yiming via Gdb <gdb@sourceware.org> writes:
>
>> Hi GDB maintainers,
>>
>> I am seeing a possible GDB source-line lookup issue while remote-debugging a
>> bare-metal RISC-V ELF.
>>
>> Environment:
>> - GDB: 15.2.90.20241210-git, Xuantie-900 elf newlib gcc Toolchain V3.2.0
>> B-20250627
>> - GCC: 14.1.1 20240710, same Xuantie toolchain
>> - ld: GNU ld 2.42.50
>> - QEMU: qemu-system-riscv64 8.2.94 (cskysim V5.2.8 B-20250721)
>> - Host: Windows 10.0.19045.6466
>>
>> Build flags:
>>
>>   -O0 -g -ffunction-sections -fdata-sections -Wl,--gc-sections
>>
>> The failing ELF is linked as a bare-metal image with .text VMA = 0x0.
>>
>> Reproducer outline:
>>
>>   target remote :1234
>>   load
>>   b main
>>   c
>>   s
>>   s
>>   n
>>   n
>>   n
>>   n
>>
>> After stepping out of SPI_ModifyGlobalReg(), GDB prints only:
>>
>>   0x00000000000002dc in I2C_PinMuxSetup ()
>>
>> Expected:
>>
>>   I2C_PinMuxSetup (...) at ../src/demoI2c.c:36
>>
>> The line information appears to exist:
>>
>>   addr2line -e LRV4201_SPI_I2C_2.elf 0x2dc
>>   -> ../src/demoI2c.c:36
>>
>> Relevant symbols:
>>
>>   0000000000000000 T Reset_Handler
>>   00000000000002ca T I2C_PinMuxSetup
>>   0000000000000920 T SPI_ModifyGlobalReg
>>
>> Additional observations:
>>
>> 1. If the linker script changes .text from 0x0 to a non-zero address, the
>>    GDB problem disappears.
>> 2. If .text still starts at 0x0 but Reset_Handler is placed in .text instead
>>    of .text.init, the problem also disappears.
>> 3. The failing ELF contains many zero-address decoded line-table rows from
>>    demoI2c.c/demoSpi.c. A no-gc build and a reduced working project do not.
>>
>> I attached a small archive with decoded line tables, objdump section
>> headers,
>> addr2line output, build flags, linker script, and relevant sources. The full
>> ELFs are not attached because of the mailing list size limit, but I can
>> provide
>> them or file a Bugzilla issue if preferred.
>>
>
> If you could file a bugzilla, include this description, and attach
> everything including the ELFs, that would make things easier.  If you
> post the link I'll try to take a look when I have time.
>
> I'm not surprised that there are issues here, some of the older GDB code
> still makes use of 0 as a "magic" flag indicating no-data, etc.  I've
> worked on targets that allow code to be placed at address 0, and fixed
> some of these issues in the past, so it would be nice to fix this one
> too.

I took a look into this and opened this bug:

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

The problem originates from the linker's function garbage collection
(IMHO).

Garbage collection deletes the function sections, but doesn't
(unfortunately) try to patch up any of the DWARF.  As a result things
like `.debug_rnglists` which point at a deleted function are left with a
start address of 0, the range of the deleted function is effectively
moved to start at address zero.

The `.debug_rnglists` is then used by GDB when building the address map
for its compunit_symtab objects (effectively a DWARF compilation unit).

These compunit_symtab are expanded lazily depending on the order in
which you make use of them, so if you first visit a compunit_symtab
which contains a garbage collected function then this compunit_symtab
will always be the first that GDB checks when looking for an address.
The garbage collected function, with its range starting at 0, in effect
"claims" that range of addresses.

There are some heuristics in GDB to try and spot garbage collection and
try to fix up some of the confusing incoming data, but it's not perfect,
and clearly in this case, it isn't sufficient.

I don't have a plan for fixing this in GDB right now.

Thanks,
Andrew

Re: Fwd: RISC-V bare-metal: GDB loses source line info when .text starts at 0x0

[Andrew Burgess via Gdb]

Andrew Burgess <aburgess@redhat.com> writes:

> Andrew Burgess <aburgess@redhat.com> writes:
>
>> Zhao Yiming via Gdb <gdb@sourceware.org> writes:
>>
>>> Hi GDB maintainers,
>>>
>>> I am seeing a possible GDB source-line lookup issue while remote-debugging a
>>> bare-metal RISC-V ELF.
>>>
>>> Environment:
>>> - GDB: 15.2.90.20241210-git, Xuantie-900 elf newlib gcc Toolchain V3.2.0
>>> B-20250627
>>> - GCC: 14.1.1 20240710, same Xuantie toolchain
>>> - ld: GNU ld 2.42.50
>>> - QEMU: qemu-system-riscv64 8.2.94 (cskysim V5.2.8 B-20250721)
>>> - Host: Windows 10.0.19045.6466
>>>
>>> Build flags:
>>>
>>>   -O0 -g -ffunction-sections -fdata-sections -Wl,--gc-sections
>>>
>>> The failing ELF is linked as a bare-metal image with .text VMA = 0x0.
>>>
>>> Reproducer outline:
>>>
>>>   target remote :1234
>>>   load
>>>   b main
>>>   c
>>>   s
>>>   s
>>>   n
>>>   n
>>>   n
>>>   n
>>>
>>> After stepping out of SPI_ModifyGlobalReg(), GDB prints only:
>>>
>>>   0x00000000000002dc in I2C_PinMuxSetup ()
>>>
>>> Expected:
>>>
>>>   I2C_PinMuxSetup (...) at ../src/demoI2c.c:36
>>>
>>> The line information appears to exist:
>>>
>>>   addr2line -e LRV4201_SPI_I2C_2.elf 0x2dc
>>>   -> ../src/demoI2c.c:36
>>>
>>> Relevant symbols:
>>>
>>>   0000000000000000 T Reset_Handler
>>>   00000000000002ca T I2C_PinMuxSetup
>>>   0000000000000920 T SPI_ModifyGlobalReg
>>>
>>> Additional observations:
>>>
>>> 1. If the linker script changes .text from 0x0 to a non-zero address, the
>>>    GDB problem disappears.
>>> 2. If .text still starts at 0x0 but Reset_Handler is placed in .text instead
>>>    of .text.init, the problem also disappears.
>>> 3. The failing ELF contains many zero-address decoded line-table rows from
>>>    demoI2c.c/demoSpi.c. A no-gc build and a reduced working project do not.
>>>
>>> I attached a small archive with decoded line tables, objdump section
>>> headers,
>>> addr2line output, build flags, linker script, and relevant sources. The full
>>> ELFs are not attached because of the mailing list size limit, but I can
>>> provide
>>> them or file a Bugzilla issue if preferred.
>>>
>>
>> If you could file a bugzilla, include this description, and attach
>> everything including the ELFs, that would make things easier.  If you
>> post the link I'll try to take a look when I have time.
>>
>> I'm not surprised that there are issues here, some of the older GDB code
>> still makes use of 0 as a "magic" flag indicating no-data, etc.  I've
>> worked on targets that allow code to be placed at address 0, and fixed
>> some of these issues in the past, so it would be nice to fix this one
>> too.
>
> I took a look into this and opened this bug:
>
>   https://sourceware.org/bugzilla/show_bug.cgi?id=34389
>
> The problem originates from the linker's function garbage collection
> (IMHO).
>
> Garbage collection deletes the function sections, but doesn't
> (unfortunately) try to patch up any of the DWARF.  As a result things
> like `.debug_rnglists` which point at a deleted function are left with a
> start address of 0, the range of the deleted function is effectively
> moved to start at address zero.
>
> The `.debug_rnglists` is then used by GDB when building the address map
> for its compunit_symtab objects (effectively a DWARF compilation unit).
>
> These compunit_symtab are expanded lazily depending on the order in
> which you make use of them, so if you first visit a compunit_symtab
> which contains a garbage collected function then this compunit_symtab
> will always be the first that GDB checks when looking for an address.
> The garbage collected function, with its range starting at 0, in effect
> "claims" that range of addresses.
>
> There are some heuristics in GDB to try and spot garbage collection and
> try to fix up some of the confusing incoming data, but it's not perfect,
> and clearly in this case, it isn't sufficient.
>
> I don't have a plan for fixing this in GDB right now.

OK, actually, I did have one idea.  If you feel like compiling GDB, I
attached a patch to the bug report which resolves the simple reproducer
I create for the bug.  It would be great to know if this also resolves
your original issue or not.

If it does then I will write a proper commit message for the patch and
post it to the mailing list.

Thanks,
Andrew