This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Repost ARM frame patches
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Richard dot Earnshaw at arm dot com, gdb-patches at sources dot redhat dot com
- Date: Mon, 09 Feb 2004 12:12:17 +0000
- Subject: Re: [RFA] Repost ARM frame patches
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw 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.