Re: frame_register_unwind(): "frame != NULL" assertion failure

[Andrew Cagney <ac131313@redhat.com>]

> 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