From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32026 invoked by alias); 9 Feb 2004 12:12:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32018 invoked from network); 9 Feb 2004 12:12:29 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sources.redhat.com with SMTP; 9 Feb 2004 12:12:29 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id i19CCH23013992; Mon, 9 Feb 2004 12:12:17 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id i19CCHX24353; Mon, 9 Feb 2004 12:12:17 GMT Message-Id: <200402091212.i19CCHX24353@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Daniel Jacobowitz cc: Richard.Earnshaw@arm.com, gdb-patches@sources.redhat.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: [RFA] Repost ARM frame patches In-reply-to: Your message of "Sat, 07 Feb 2004 23:11:09 EST." <20040208041109.GB13033@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Feb 2004 12:12:00 -0000 From: Richard Earnshaw X-SW-Source: 2004-02/txt/msg00196.txt.bz2 > 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.