mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-01-30 12:44:10 +08:00
30baee6865
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. |
||
---|---|---|
.. | ||
ada-scopes | ||
catch-exception | ||
ada-scopes.exp | ||
args-env.c | ||
args-env.exp | ||
attach.c | ||
attach.exp | ||
basic-dap.c | ||
basic-dap.exp | ||
bt-inner.c | ||
bt-main.c | ||
bt-nodebug.exp | ||
catch-exception.exp | ||
cond-bp.c | ||
cond-bp.exp | ||
cwd.exp | ||
cxx-exception.cc | ||
cxx-exception.exp | ||
frameless.c | ||
frameless.exp | ||
hover.c | ||
hover.exp | ||
log-message.c | ||
log-message.exp | ||
memory.c | ||
memory.exp | ||
modules-solib.c | ||
modules.c | ||
modules.exp | ||
pause.exp | ||
remote-dap.exp | ||
scopes.c | ||
scopes.exp | ||
sources.c | ||
sources.exp | ||
stop-at-main.exp | ||
terminate.exp | ||
type_check.exp | ||
type_check.py |