From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2456 invoked by alias); 29 Jun 2009 14:33:07 -0000 Received: (qmail 2445 invoked by uid 22791); 29 Jun 2009 14:33:06 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 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; Mon, 29 Jun 2009 14:32:59 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 182C4108CB; Mon, 29 Jun 2009 14:32:57 +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 01764108B0; Mon, 29 Jun 2009 14:32:57 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MLHuh-0000Rv-AB; Mon, 29 Jun 2009 10:32:55 -0400 Date: Mon, 29 Jun 2009 14:33:00 -0000 From: Daniel Jacobowitz To: Andreas Schwab Cc: gdb-patches@sourceware.org Subject: Re: Don't overshoot when executing cfa instructions Message-ID: <20090629143255.GA25594@caradoc.them.org> Mail-Followup-To: Andreas Schwab , gdb-patches@sourceware.org References: <20090627223341.GB14420@caradoc.them.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-06/txt/msg00811.txt.bz2 On Mon, Jun 29, 2009 at 03:19:09PM +0200, Andreas Schwab wrote: > Daniel Jacobowitz writes: > > > Actually, before approving this I have a question. What about state > > changes caused by the branch? > > > > I remember a similar problem with location lists. Before the branch, > > a variable lives at some location. Inside the called function, it is > > gone. Did we ever find a representation for that? Does it rely > > on the instruction after the branch marking the register as clobbered? > > Do you have a testcase, or a hint how to create one? We currently deal with this by implicit knowledge of the ABI (dwarf2_init_reg methods). I couldn't coax either GCC or RealView into producing an example, but here's what I was thinking of: foo: .cfi_startproc mov sp, fp .cfi_def_cfa_register fp push r0 push r1 bl bar @ clobber r0, r1, r2 .cfi_offset r0, -4 .cfi_offset r1, -8 .cfi_undefined r2 pop r0, r1 .cfi_same_value r0 .cfi_same_value r1 ret I think this CFI is unlikely, but correct. At "bl bar" r1 can be found in r1. After that instruction it must be found on the stack. GCC already combines pushes in this way although it will place the CFI after the last push. But if it emitted full undefined markers, isn't that where the r2 marker would have to go? -- Daniel Jacobowitz CodeSourcery