From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12622 invoked by alias); 21 Nov 2005 10:32:26 -0000 Received: (qmail 12615 invoked by uid 22791); 21 Nov 2005 10:32:26 -0000 X-Spam-Check-By: sourceware.org Received: from ip127.bb146.pacific.net.hk (HELO stl.com.hk) (202.64.146.127) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 21 Nov 2005 10:32:24 +0000 Received: from 221.196.17.210.dyn.pacific.net.hk ([210.17.196.221] helo=[192.168.1.10]) by stl.com.hk with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Ee8tb-0002zC-0A; Mon, 21 Nov 2005 18:27:35 +0800 Message-ID: <4381A22B.20707@tausq.org> Date: Mon, 21 Nov 2005 10:32:00 -0000 From: Randolph Chung User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) MIME-Version: 1.0 To: Jim Blandy CC: gdb@sources.redhat.com Subject: Re: Argument pointers, dwarf and prologue analysis References: <4381603E.1060500@tausq.org> <8f2776cb0511202342k23a2e537pe3cbf569a94c3d03@mail.gmail.com> In-Reply-To: <8f2776cb0511202342k23a2e537pe3cbf569a94c3d03@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00445.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. Yeah, I filed a gcc bug about this yesterday.... > 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. Well, for gcc, preceeding every call will be a setting of the argument pointer is a relative offset to the stack pointer. We only need to know the value of r29 and r20 during the prologue, so I would argue that if we know the value of r29 immediately before the call (at the call site), then prologue analysis will be able to tell you where the arguments are stored. that is, there will always be: caller: ... ldo -48(%sp), %r29 ... bl callee, %r2 callee: ... ldo -64(%r29), %r20 stw %arg0, 4(%r20) ... randolph