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

Andrew Burgess <[email protected]> writes:

> Andrew Burgess <[email protected]> writes:
>
>> Zhao Yiming via Gdb <[email protected]> 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