Re: [RFA] Repost ARM frame patches

[Richard Earnshaw <rearnsha at arm dot com>]

> On Fri, Sep 05, 2003 at 10:50:23AM +0100, Richard Earnshaw wrote:
> > > On Tue, Sep 02, 2003 at 11:52:26PM +0100, Richard Earnshaw wrote:
> > > > My only question is, once we start using the dwarf2 unwinder, can it cope 
> > > > with the fact that gcc currently does not emit frame unwind information 
> > > > for Thumb code? (ie can it handle a mix of code that uses dwarf2 and 
> > > > traditional unwinding?)
> 
> > Consider
> > 
> > int func(void) { return 0;}
> > 
> > Which compiles to 
> > 
> > 	mov	r0, #0
> > 	bx	lr
> > 
> > I would have thought that wouldn't need any frame unwind information.  So 
> > we would have a problem distinguishing trivial cases from "not generated" 
> > cases.
> 
> Yes.  Now that GCC 3.4 does generate dwarf2 unwind information for
> Thumb, I compared the generated information for that trivial function
> to the previously produced empty FDE.  As you'd expect, there is no way
> to tell them apart.
> 
> Of course, ignoring dwarf2 FDEs containing no information would
> probably not hurt much - the prologue unwinder could handle the above
> function just fine.  But it still seems a terrible hack.
> 
> What do you think?  My inclination is to wait until after the release
> of GCC 3.4, and then switch on dwarf2 unwinding for ARM.  A second
> option would be to simply switch it on now.  A third would be to prefer
> the prologue unwinder for Thumb; not too hard to arrange.

Well, I've always thought the prologue unwinder on Thumb was irretrievably 
broken...  It's not much better in ARM state: there are just too many 
things where you have to guess.

My inclination would be to switch it on now for arm-linux and 
arm-netbsdelf if that is possible (since these platforms are predominantly 
ARM only at present and hence have had FDE generation for a while now) and 
to certainly switch it on for arm-elf as soon as 3.4 is out.

If doing the above is not really feasible, then I'd just switch it on now 
and declare thumb code without a FDE description to be buggy.

But then, I'm radical in that way.... :-)

R.