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

[Zhao Yiming via Gdb <gdb@sourceware.org>]

[-- 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 --]