From: Andrew Burgess via Gdb <gdb@sourceware.org>
To: Zhao Yiming <zjjj31@gmail.com>, gdb@sourceware.org
Subject: Re: Fwd: RISC-V bare-metal: GDB loses source line info when .text starts at 0x0
Date: Mon, 06 Jul 2026 16:18:52 +0100 [thread overview]
Message-ID: <87wlv8tacj.fsf@redhat.com> (raw)
In-Reply-To: <CAGnW-qix0m4Y1zJG8OE640OkJZXwbsHX-Jk5JH6sfFy1aOvuNw@mail.gmail.com>
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
prev parent reply other threads:[~2026-07-06 15:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAGnW-qid2eYJeXy1UCvv5BiZZv4wKFVDmWsmZgD2cKKdWcNKzw@mail.gmail.com>
2026-06-29 6:41 ` Zhao Yiming via Gdb
2026-07-06 15:18 ` Andrew Burgess via Gdb [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wlv8tacj.fsf@redhat.com \
--to=gdb@sourceware.org \
--cc=aburgess@redhat.com \
--cc=zjjj31@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox