From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13695 invoked by alias); 21 Nov 2005 14:08:26 -0000 Received: (qmail 13686 invoked by uid 22791); 21 Nov 2005 14:08:24 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 21 Nov 2005 14:08:18 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EeCL3-000533-J8; Mon, 21 Nov 2005 09:08:09 -0500 Date: Mon, 21 Nov 2005 14:08:00 -0000 From: Daniel Jacobowitz To: Randolph Chung Cc: Jim Blandy , gdb@sources.redhat.com Subject: Re: Argument pointers, dwarf and prologue analysis Message-ID: <20051121140809.GA18686@nevyn.them.org> Mail-Followup-To: Randolph Chung , Jim Blandy , gdb@sources.redhat.com References: <4381603E.1060500@tausq.org> <8f2776cb0511202342k23a2e537pe3cbf569a94c3d03@mail.gmail.com> <4381A22B.20707@tausq.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4381A22B.20707@tausq.org> User-Agent: Mutt/1.5.8i 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/msg00446.txt.bz2 On Mon, Nov 21, 2005 at 06:32:11PM +0800, Randolph Chung wrote: > >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) > ... > So you're saying you have to do (A) backwards code analysis from the call site to compute r29, and then (B) forward code analysis from the function start to compute r20 relative to r29, and then (C) use dwarf debug information to find arguments relative to r20, and then (D) hope that GCC doesn't decide to use r20 for something different, since it doesn't seem to be a traditional "frame pointer"? There's a lot more prayer in that method than there really ought to be. And GCC will probably take some severe liberties with where the set of %r29 is, so I'm skeptical that you can do the call site analysis. How does GDB cope today? A lot of guessing and failing? I'd recommend ignoring the call site/ABI bits. They're too unreliable. The real problem is that you can't recover %r20. You're thinking in terms of finding the offset relative to the CFA where these things are stored, which is why you've got a solution that relies on analyzing the caller. But think about the problem in terms of the callee for a moment. The function doesn't care what the offset relative to the CFA is. It cares what the offset relative to the incoming %r29 and later %r20 is. And then, if it makes any calls, it had better still know where its own arguments went! So that should be in the debug info somehow. We've got dwarf unwind information to play with now. Even with the new additions in dwarf3, it's not so good at representing what you need. I'd need to see a larger example to know how we could, or couldn't, do this. -- Daniel Jacobowitz CodeSourcery, LLC