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: Daniel Jacobowitz <drow at mvista dot com>
- To: Richard dot Earnshaw at arm dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 7 Feb 2004 23:11:09 -0500
- Subject: Re: [RFA] Repost ARM frame patches
- References: <20030903204139.GA9605@nevyn.them.org> <200309050950.h859oNV23553@pc960.cambridge.arm.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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer