frame_register_unwind(): "frame != NULL" assertion failure
Andrew Cagney
ac131313@redhat.com
Mon Feb 17 15:37:00 GMT 2003
> 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
Hmm, yes. I took the name `read_next_frame_reg()' at face value :-(
That leaves us with:
> - we're initializing the saved regs for
>> fci right now, and find_proc_desc wants a frame to read registers out
>> of.
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
OLD_NEXT_FRAME->unwind()
instead of relying on:
HALF_INITIALIZED_NEW_PREV_FRAME->next->unwind()
(the sentinal frame unwind still needs to be cleaned up).
The one fly in the ointment is that the sentinel frame unwinder is still
hardwired.
Anyway, Kevin,
/* Use proc_desc calculated in frame_chain */
proc_desc =
get_next_frame (fci)
? cached_proc_desc
: 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.
Andrew
More information about the Gdb
mailing list