Re: [rfc] trad-frame change

[Daniel Jacobowitz <drow@false.org>]

On Wed, Mar 03, 2004 at 03:20:44PM -0500, Andrew Cagney wrote:
> >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.
> 
> So there are really two variants - o32sigreturn and rt_sigreturn (with 
> constants computed from the architecture vector)?

I don't see much point in distinguishing them that way, honestly.  The
difference between o32 sigreturn and o32 rt_sigreturn is about the same
as the difference between n32 and n64.  Sure, you could put the
constants in the architecture tdep vector... but why bother?

And it may be silly, but there's nothing stopping a theoretical
hand-written program from using a different ABI's sigreturn syscall.

> >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.
> 
> I'll think about that, I may need to change the unwinder object anyway.
> 
> Just remember that it is the number of unique addresses accessed (0 vs 1 
> vs 2 ...) and not the number of times each address is accessed that is 
> going to be important - multiple accesses to a single address can be 
> handled with a cache.

We really should turn on that cache someday.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer