From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30981 invoked by alias); 1 Sep 2009 22:50:14 -0000 Received: (qmail 30972 invoked by uid 22791); 1 Sep 2009 22:50:13 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,J_CHICKENPOX_22 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Sep 2009 22:50:06 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id B875B108C6; Tue, 1 Sep 2009 22:50:04 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 910461055A; Tue, 1 Sep 2009 22:50:04 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MicAt-0007dN-S4; Tue, 01 Sep 2009 18:50:03 -0400 Date: Tue, 01 Sep 2009 22:50:00 -0000 From: Daniel Jacobowitz To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: RFC: DW_OP_call_frame_cfa, again Message-ID: <20090901225003.GA28876@caradoc.them.org> Mail-Followup-To: Tom Tromey , gdb-patches@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00037.txt.bz2 On Tue, Aug 11, 2009 at 02:49:02PM -0600, Tom Tromey wrote: > This version implements Daniel's idea of checking the frame unwinder. > If you read the followup message (above) you'll see that this patch is > different from what I talked about there; that approach doesn't work > since the DWARF frame base sniffer is not registered for many > architectures. Jan suggested the current approach. Am I correct that this works only if all unwinders for this architecture use the same CFA notion that DWARF-2 would? If so - probably already a requirement - it deserves a comment. > One further issue is that this interacts poorly with the i386 epilogue > unwinder. I punted on this issue for the time being. However, with GCC > 4.5, I think the DWARF unwinder is supposed to work fine for epilogues > -- so can we make the epilogue unwinder conditional? Is this special > unwinder only needed for reverse execution? If so, could we make it > conditional on when that mode is enabled? It's useful at other times. My canonical torture test for this is a software watchpoint on a local variable, and then "next" over the application's first call to printf - with glibc debug info. You'll go through the PLT, ld.so, printf itself, nested functions, et cetera. Without an epilogue unwinder the only reason this survives is an in_epilogue_p or similar hack in the watchpoint checking code. With GCC 4.5 the DWARF unwinder ought to work fine for epilogues on specific platforms, not all. On Tue, Sep 01, 2009 at 12:08:25PM -0600, Tom Tromey wrote: > >>>>> "Tom" == Tom Tromey writes: > > Tom> Here is a new version of my patch to implement DW_OP_call_frame_cfa. > Tom> Previous thread here: > Tom> http://sourceware.org/ml/gdb-patches/2009-06/msg00191.html > Tom> With followup the next month (I wish our mailing list archive handled > Tom> this more nicely): > Tom> http://sourceware.org/ml/gdb-patches/2009-07/msg00570.html > > Here is an updated version. This fixes a couple of bugs found by > testing it in Fedora rawhide. > > I'm happy with this version, so I plan to check it in next week or so. > Comment soon if you think it needs some change. Aside from above, this version seems fine. -- Daniel Jacobowitz CodeSourcery