Re: [rfc] trad-frame change

[Daniel Jacobowitz <drow@false.org>]

On Wed, Mar 03, 2004 at 11:43:20AM -0500, Andrew Cagney wrote:
> Think of this as a pseudo patch.
> 
> I'm looking to extend the trad-frame code so that it includes the interface:
> 
>   trad_frame_append (gdbarch, frame_type, frame_sniffer, frame_cache);
> 
> This would do all the housekeeping necessary to create a FRAME_TYPE 
> unwinder implemented with FRAME_SNIFFER and FRAME_CACHE functions.  The 
> second function would have the interface:
> 
>   struct trad_frame_cache
>   {
>     struct frame_id this_id;
>     CORE_ADDR this_base;
>     struct trad_frame *saved_regs;
>   };
> 
>   void frame_cache (struct frame_info *next_frame, struct 
> trad_frame_cache *this_cache);
> 
> and would be called _once_ to populate the entire trad-frame cache. 
> After that frame ID and register requests would be handled directly.
> 
> My rationale is simple.  Having just churned out unwinders for two 
> architectures I'm seeing a pattern that suggests this would make life 
> easier:

Sounds pretty nice to me.  For what it's worth, I'm testing a sigtramp
unwinder on MIPS/Linux that could almost but not quite use this:

+struct mips_prologue_cache
+{
+  /* The stack pointer at the time this frame was created; i.e. the
+     caller's stack pointer when this function was called.  It is used
+     to identify this frame.  */
+  CORE_ADDR prev_sp;
+
+  CORE_ADDR tramp_start;
+
+  int kind;
+
+  /* Saved register offsets.  */
+  struct trad_frame_saved_reg *saved_regs;
+};

(so that the frame ID is constant for both instructions of the
trampoline).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer