Re: [rfc] trad-frame change

[Daniel Jacobowitz <drow@false.org>]

On Wed, Mar 03, 2004 at 01:34:23PM -0500, Andrew Cagney wrote:
> >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).
> 
> .. and frame_id_unwind() looks something like:
> 
> 	frame_id_build (cache->prev_sp, cache->tramp_start)?
> 
> the trad-frame chache instead has the field:
> 
>     struct frame_id this_id;
> 
> which is equivalent - the ID being constructed up front.

Yes, precisely - I missed seeing this_id in the bit you posted.

> What is "kind"?

There are four kinds of signal frames on MIPS/Linux that we have to
recognize:
  - o32 sigreturn
  - o32 rt_sigreturn
  - n32 rt_sigreturn
  - n64 rt_sigreturn

They're all basically the same but the offsets differ.  Kind could be
moved out of the cache, I think, since it isn't used after the cache is
filled.  So I could use your new mechanism after all.

What would _really_ be nice would be a way to pass the kind from the
sniffer (which really just calls PC_IN_SIGTRAMP) to the frame creation
code... not have to read inferior memory to figure out which it is,
twice.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer