This is the mail archive of the
mailing list for the GDB project.
Re: frame_register_unwind(): "frame != NULL" assertion failure
- From: ac131313 at redhat dot com (Andrew Cagney)
- To: Kevin Buettner <kevinb at redhat dot com>
- Cc: Andrew Cagney <ac131313 at redhat dot com>,Daniel Jacobowitz <drow at mvista dot com>, gdb at sources dot redhat dot com
- Date: Mon, 17 Feb 2003 20:54:13 -0500 (EST)
- Subject: Re: frame_register_unwind(): "frame != NULL" assertion failure
> On Feb 17, 4:37pm, Andrew Cagney wrote:
> > /* 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.
e.g., The mips should be updated to use the new frame unwind
mechanisms and, as part of this, implement a custom sentinel frame
unwinder (which would be passed the sentinal frame as a parameter).
The MIPS specific sentinel frame unwind code could then call
find_proc_desc() with the sentinel frame making all the frame==NULL
tests redundant. In the mean time, this call to find_proc_desc()
passes in an explicit (rather than implicit) NULL (by definition
current_frame-> == NULL). This way the task of tracking down if/where
find_proc_desc is called with a NULL frame is made much much easier.
> I will do this, but I really do not think it's the best solution. (If
> we're going to be checking for frame == NULL, then why did you introduce
> sentinel frames in the first place?)
It is part of the hack. The `correct fix' (rewrite MIPS to use the unwind
mechanism) would eliminate that call.