This is the mail archive of the
mailing list for the GDB project.
Re: [unwind-20030108-branch] Convert d10v to unwind mechanims
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Mon, 13 Jan 2003 12:24:23 -0500
- Subject: Re: [unwind-20030108-branch] Convert d10v to unwind mechanims
- References: <3E22F527.email@example.com>
On Mon, Jan 13, 2003 at 12:19:35PM -0500, Andrew Cagney wrote:
> The attached converts the d10v to the new unwind mechanism. It creates
> a new file:
> which implements a d10v specific frame unwinder. The new file contains
> one obvious hack do_d10v_frame_pop() (that needs to be added to the
> standard set of unwind functions and purged of deprecated code), and
> still needs some d10v code cleanup (e.g., shouldn't need to specify the
> unused init_frame_extra_info).
> In implementing this, the code adds frame-unwind.[hc] which implements a
> mechanims for maintaining registrary of frame unwinders and selecting
> one (is frame-unwinder, or frame-winder, or ..., better?).
> Finally, it contains the change:
> get_frame_base (struct frame_info *fi)
> - return fi->frame;
> + struct frame_id id = frame_id_unwind (fi->next);
> + return id.base;
> The issue is that, for a dummy frame, the code delays doing an unwind of
> the previous frame until it's rewuested. This, unfortunatly, leaves the
> frame's base undefined. A case of duplicating information finally
> comming back and biteing us. The above is the correct fix. Further, I
> think it highlights why I need to make `struct frame_info' opaque - so
> that this redundency can be eliminated.
> Now to break this down into digestable chunks that can be reviewed for
> the mainline.
I like it. I've got a tangential style question that I want to ask
now, though... if you're creating additional target-specific files, can
we consider putting them under config/ instead of in the top level?
MontaVista Software Debian GNU/Linux Developer