I noticed this problem while preparing the initial submission for the
ROCm GDB port. One particularity of this patch set is that it does not
support unwinding frames, that requires support of some DWARF extensions
that will come later. It was still possible to run to a breakpoint and
print frame #0, though.
When rebasing on top of the frame_info_ptr work, GDB started tripping on
a prepare_reinflate call, making it not possible anymore to event print
the frame when stopping on a breakpoint. One thing to know about frame
0 is that its id is lazily computed when something requests it through
get_frame_id. See:
23912acd40/gdb/frame.c (L2070-2080)
So, up to that prepare_reinflate call, frame 0's id was not computed,
and prepare_reinflate, calling get_frame_id, forces it to be computed.
Computing the frame id generally requires unwinding the previous frame,
which with my ROCm GDB patch fails. An exception is thrown and the
printing of the frame is simply abandonned.
Regardless of this ROCm GDB problem (which is admittedly temporary, it
will be possible to unwind with subsequent patches), we want to avoid
prepare_reinflate to force the computing of the frame id, for the same
reasons we lazily compute it in the first place.
In addition, frame 0's id is subject to change across a frame cache
reset. This is why save_selected_frame and restore_selected_frame have
special handling for frame 0:
23912acd40/gdb/frame.c (L1841-1863)
For this last reason, we also need to handle frame 0 specially in
prepare_reinflate / reinflate. Because the frame id of frame 0 can
change across a frame cache reset, we must not rely on the frame id from
that frame to reinflate it. We should instead just re-fetch the current
frame at that point.
This patch adds a frame_info_ptr::m_cached_level field, set in
frame_info_ptr::prepare_reinflate, so we can tell if a frame is frame 0.
There are cases where a frame_info_ptr object wraps a sentinel frame,
for which frame_relative_level returns -1, so I have chosen the value -2
to represent "invalid frame level", for when the frame_info_ptr object
is empty.
In frame_info_ptr::prepare_reinflate, only cache the frame id if the
frame level is not 0. It's fine to cache the frame id for the sentinel
frame, it will be properly handled by frame_find_by_id later.
In frame_info_ptr::reinflate, if the frame level is 0, call
get_current_frame to get the target's current frame. Otherwise, use
frame_find_by_id just as before.
This patch should not have user-visible changes with upstream GDB. But
it will avoid forcing the computation of frame 0's when calling
prepare_reinflate. And, well, it fixes the upcoming ROCm GDB patch
series.
Change-Id: I176ed7ee9317ddbb190acee8366e087e08e4d266
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
The assertion
gdb_assert (m_cached_id != null_frame_id);
is always true, as comparing equal to null_frame_id is always false
(it's the first case in frame_id::operator==, not sure why it's not this
way, but that's what it is).
Replace the comparison with a call to frame_id_p.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I93986e6a85ac56353690792552e5b3b4cedec7fb
I don't see any particular reason why the implementations of the
frame_info_ptr object are in the header file. It only seems to add some
complexity. Since we can't include frame.h in frame-info.h, we have to
add declarations of functions defined in frame.c, in frame-info.h. By
moving the implementations to a new frame-info.c, we can avoid that.
Change-Id: I435c828f81b8a3392c43ef018af31effddf6be9c
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
