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 buzzard dot freeserve dot co dot uk, gdb-patches at sources dot redhat dot com, Richard dot Earnshaw at arm dot com
- Date: Fri, 05 Sep 2003 10:50:23 +0100
- Subject: Re: [RFA] Repost ARM frame patches
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> On Tue, Sep 02, 2003 at 11:52:26PM +0100, Richard Earnshaw wrote:
> > Daniel,
> >
> > My appologies for not reviewing this before. Just way too much day job...
> >
> > It looks fine to me (at least, it seems better than what's there at
> > present).
> >
> > 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?)
>
> I was going to say yes, but...
>
> drow@nevyn:/big/fsf/projects/arm/obj/gdb/testsuite/interwork% readelf -wf test1.o
> The section .debug_frame contains:
>
> 00000000 0000000c ffffffff CIE
> Version: 1
> Augmentation: ""
> Code alignment factor: 1
> Data alignment factor: -4
> Return address column: 14
>
> DW_CFA_def_cfa: r13 ofs 0
>
> 00000010 0000000c 00000000 FDE cie=00000000 pc=00000000..0000001c
>
> 00000020 0000000c 00000000 FDE cie=00000000 pc=0000001c..00000046
>
>
> i.e. GCC emits _empty_ dwarf unwind information for thumb functions,
> rather than none at all. That's unlikely to work. We'd need to modify
> the dwarf2 unwinder to ignore empty FDEs.
>
> I'll check in the non-dwarf parts now, and then we can figure out what
> to do about that.
Though of course a trivial leaf function *will* have an empty FDE.
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.
R.