From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17402 invoked by alias); 21 Nov 2005 07:42:34 -0000 Received: (qmail 17394 invoked by uid 22791); 21 Nov 2005 07:42:33 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.202) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Nov 2005 07:42:33 +0000 Received: by zproxy.gmail.com with SMTP id l1so710694nzf for ; Sun, 20 Nov 2005 23:42:31 -0800 (PST) Received: by 10.36.71.15 with SMTP id t15mr2782684nza; Sun, 20 Nov 2005 23:42:31 -0800 (PST) Received: by 10.37.2.35 with HTTP; Sun, 20 Nov 2005 23:42:31 -0800 (PST) Message-ID: <8f2776cb0511202342k23a2e537pe3cbf569a94c3d03@mail.gmail.com> Date: Mon, 21 Nov 2005 07:42:00 -0000 From: Jim Blandy To: Randolph Chung Subject: Re: Argument pointers, dwarf and prologue analysis Cc: gdb@sources.redhat.com In-Reply-To: <4381603E.1060500@tausq.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4381603E.1060500@tausq.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00441.txt.bz2 It seems to me that the real problem is that the Dwarf debugging info doesn't accurately describe where the bar's arguments live after the call to foo. That is, when you return from foo, since r20 is caller-saved, its value is unknown, and it's incorrect for the debugging info to claim that the debugger can find the variables relative to its value. I don't think that the wacky idea about recovering r20's value by looking at the call site will work. I mean, if r20 is a scratch register, you have no way of knowing that it hasn't been used for something else since the function was entered, right? I admit I don't really understand that. But I think it's clear that the locations of the variables in the debug info is incorrect. There's all kinds of heuristic crud in gcc/dwarf2out.c where it tries to figure out the right register to use as the base for variable locations (maybe I'm thinking of the way the CFI code chooses a CFA register; I don't really remember), but it seemed like it could be easily confused by the use of temporaries like r20 in the example you posted.