On Tue, Aug 1, 2023 at 10:07 PM Tom Tromey via Gdb-patches <
gdb-patches@sourceware.org> wrote:

> A co-worker pointed out that gdb's DAP implementation might return an
> integer for the name of a stack frame, like:
>
>     {"id": 1, "name": 93824992310799, ...}
>
> This can be seen currently in the logs of the bt-nodebug.exp test
> case.
>
> What is happening is that FrameDecorator falls back on returning the
> PC when the frame's function symbol cannot be found, relying on the
> gdb core to look up the minsym and print its name.
>
> This can actually yield the wrong answer sometimes, because it falls
> into the get_frame_pc / get_frame_address_in_block problem -- if the
> frame is at a call to a noreturn function, the PC in this case might
> appear to be in the next function in memory.  For more on this, see:
>
>     https://sourceware.org/bugzilla/show_bug.cgi?id=8416
>
> and related bugs.
>
> However, there's a different approach we can take: the code here can
> simply use Frame.name.  This handles the PC problem correctly, and
> gets us the information we need.
> ---
>
>
I tested this for Fedora-Rawhide on ppc64le. I can confirm this causes no
regressions and I can see  {"id": 1, "name": "no_debug_info",
is outputted instead of {"id": 1, "name": 268501652.