This is the mail archive of the
mailing list for the GDB project.
Re: frame_register_unwind(): "frame != NULL" assertion failure
Hmm, yes. I took the name `read_next_frame_reg()' at face value :-(
That leaves us with:
On Feb 14, 10:14am, Daniel Jacobowitz wrote:
> However, can you please first investigate modifying the start of
> mips_init_extra_frame_info() where it does:
> proc_desc = get_next_frame (fci) ? .....
> to, when get_next_frame(fci) is null, call:
> find_proc_desc (get_frame_pc (fci), fci, 1);
> that is the current, and not prev frame.
I'm pretty sure that won't work
> - we're initializing the saved regs for
>> fci right now, and find_proc_desc wants a frame to read registers out
BTW. This problem is going away. New targets should no longer need to
do all those get_next_frame(FCI) calls since the new tdep methods have
that next frame passed in.
This is also why the comment:
+ /* Note: kevinb/2003-02-13: This is a hack. The problem is that
+ get_next_frame() can return NULL when it really ought to be
+ returning the sentinel frame. So, when we detect frame == NULL,
+ just use the sentinel frame instead.
+ FIXME: Remove this hack once get_next_frame() has been fixed
+ to never return NULL. */
is misleading. get_next_frame(current_frame), by definition, is NULL.
The new tdep code uses
instead of relying on:
(the sentinal frame unwind still needs to be cleaned up).
The one fly in the ointment is that the sentinel frame unwinder is still
/* Use proc_desc calculated in frame_chain */
: find_proc_desc (get_frame_pc (fci), get_next_frame (fci), 1);
can you please change the above to be:
: find_proc_desc (get_frame_pc (fci), NULL, 1);
(with a comment) and modify read_next_frame_reg() to, when NULL, pull a
value from the register cache.