From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29819 invoked by alias); 21 Nov 2005 15:11:35 -0000 Received: (qmail 29809 invoked by uid 22791); 21 Nov 2005 15:11:34 -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 15:11:31 +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 1EeDFA-0003p6-9W; Mon, 21 Nov 2005 23:06:08 +0800 Message-ID: <4381E376.5020003@tausq.org> Date: Mon, 21 Nov 2005 15:11:00 -0000 From: Randolph Chung User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) MIME-Version: 1.0 To: Daniel Jacobowitz CC: Jim Blandy , gdb@sources.redhat.com Subject: Re: Argument pointers, dwarf and prologue analysis References: <4381603E.1060500@tausq.org> <8f2776cb0511202342k23a2e537pe3cbf569a94c3d03@mail.gmail.com> <4381A22B.20707@tausq.org> <20051121140809.GA18686@nevyn.them.org> In-Reply-To: <20051121140809.GA18686@nevyn.them.org> 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/msg00452.txt.bz2 > 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. Yeah...., except it doesn't have to be r20, it can be any register. > 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. yes, that's what i worry about too.... > How does GDB cope today? A lot of guessing and failing? It doesn't -- basically I discovered this because on hppa64-*, if you do a backtrace, gdb prints completely bogus arguments for anything other than the innermost frame. > 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. Oh, I agree -- my first instinct is that gcc is wrong in writing the debug info based on r20.... in fact I filed this as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24943 before I wrote my email to this list; but some emails I had with Dave convinced me that the problem is not as easy as I thought it would be, so I thought I'd bring it up here... > 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. What would you like to see? randolph