aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-unwind.c
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@efficios.com>2023-12-21 16:10:17 +0000
committerSimon Marchi <simon.marchi@polymtl.ca>2023-12-24 09:02:08 -0500
commit9960c5d0a05007d27cc333f5cc3e746ac5087237 (patch)
tree065c6dea2bde552e59335734e1bc88e10e8cab6e /gdb/python/py-unwind.c
parent9f02b3a0249e61be6150ff3450726573916fca91 (diff)
downloadfsf-binutils-gdb-9960c5d0a05007d27cc333f5cc3e746ac5087237.zip
fsf-binutils-gdb-9960c5d0a05007d27cc333f5cc3e746ac5087237.tar.gz
fsf-binutils-gdb-9960c5d0a05007d27cc333f5cc3e746ac5087237.tar.bz2
gdb: pass non-nullptr frame to gdbarch_value_from_register in address_from_register
address_from_register used to pass null_frame_id to gdbarch_value_from_register as "this frame"'s id, because it's possible for it to be called during unwind, when "this frame"'s id is not yet known. This create an oddity where those register struct values are created without a valid next frame id. I would much prefer for things to be consistent and have all register struct values to have a valid next frame id. Since gdbarch_value_from_register takes a frame_info_ptr now, rather than a frame_id, we can pass down "this frame", even if it doesn't have a valid id. gdbarch_value_from_register implementations can obtain the next frame from it. However, it's possible for the "this frame"'s next frame to be an inline frame, inlined in "this frame", in which case that next frame's id is also not known. So, loop until we get to the next non-inline frame (which is actually the frame where registers for "this frame" are unwound from). This is the same thing that we do in value_of_register_lazy, for the same reason. A later patch will factor out this "while next frame is inline" loop to apply it to all register struct values, so this is somewhat temporary. Change-Id: If487c82620cc5a4a4ea5807f0a0bad80ab984078
Diffstat (limited to 'gdb/python/py-unwind.c')
0 files changed, 0 insertions, 0 deletions