[RFC] Teach dwarf2-frame.c about StackGhost

[Daniel Jacobowitz]

On Sun, Apr 03, 2005 at 09:03:31PM +0200, Mark Kettenis wrote:
>    Date: Sat, 2 Apr 2005 19:34:43 -0500
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    On Sun, Apr 03, 2005 at 12:18:42AM +0200, Mark Kettenis wrote:
>    > One of the things that still keeps me from enabling the DWARF2
>    > unwinder on SPARC is the fact that it doesn't play nice with
>    > StackGhost.  Here is an attempt to make dwarf2-frame.c deal with it by
>    > introducing yet another register rule.  People might object since this
>    > is only sort of architecture independent code.  However it seems that
>    > this is the cleanest way to solve this.
> 
>    Ewww... this isn't even vaguely architecture independent code.  It
>    seems like it's in the wrong place; there's no reason StackGhost
>    must be restricted to register windows.
> 
> On the contrary.  The whole idea pretty much depends on the concept of
> register windows.  Now the number of register window architectures is
> fairly limited: SPARC, UltraSPARC and IA-64.

I have just gone and looked up the details of StackGhost.  Obviously, I
misunderstood it.  Similar mechanisms are possible elsewhere, but not
this one.

>    Here's an alternative that I think is cleaner (and will work... I
>    hope): create a sparc-specific unwinder.  Its sniffer can call the
>    dwarf2 sniffer; similarly for this_id and prev_register.  Then you can
>    handle the StackGhost cookie when you are requested to unwind the PC.
> 
> The problem here is that whether you need to apply the stackghost
> cookie is highly dependent on where exactly %i7 is stored.  If it is
> stored in the reserved stack slot then you need to apply the cookie,
> otherwise you won't.  The way you suggests makes it hard to get at
> that information.

I think it would still be fairly straightforward - but if you don't,
then I withdraw my objection.

-- 
Daniel Jacobowitz
CodeSourcery, LLC