Re: [rfc] trad-frame change

Daniel Jacobowitz
2004-03-03T18:53:22Z

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