Re: [unwind-20030108-branch] Convert d10v to unwind mechanims

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Jan 13, 2003 at 12:19:35PM -0500, Andrew Cagney wrote:
> Hello,
> 
> The attached converts the d10v to the new unwind mechanism.  It creates 
> a new file:
> 	d10v-frame.[hc]
> 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?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer