From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15266 invoked by alias); 9 Nov 2004 13:55:11 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15145 invoked from network); 9 Nov 2004 13:54:55 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 9 Nov 2004 13:54:55 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iA9DrQ7F018186; Tue, 9 Nov 2004 14:53:26 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id iA9DrSet090735; Tue, 9 Nov 2004 14:53:28 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iA9DrKjH090730; Tue, 9 Nov 2004 14:53:20 +0100 (CET) Date: Tue, 09 Nov 2004 14:35:00 -0000 Message-Id: <200411091353.iA9DrKjH090730@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb@sources.redhat.com In-reply-to: <20041109024314.GA1997@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 8 Nov 2004 21:43:14 -0500) Subject: Re: [RFC] Is skip_prologue_using_sal actually usable? References: <200411071355.iA7DtfTE002934@elgar.sibelius.xs4all.nl> <20041109024314.GA1997@nevyn.them.org> X-SW-Source: 2004-11/txt/msg00079.txt.bz2 Date: Mon, 8 Nov 2004 21:43:14 -0500 From: Daniel Jacobowitz If you want the first instruction that is not part of the prologue, then you have no more reason to skip prologues at all. My understanding is that prologue skipping accomplishes two things: B? - Get the arguments into their save slots so that we can find and display them. A? - Get the frame pointer into a sane state so we can backtrace. Well, we've taken care of (A) already - the new frame code requires being able to backtrace from the first instruction of a function, and we do it. (I think we fall down more often in the epilogue than we do in the prologue now.) Assuming the second point is (A) and the first one is (B): There are still problems here on some badly maintained archs, but in general this should be OK. We currently make no effort on getting things right for the epilogue. What we need is a coherent approach to (B). Future versions of GCC will make this much easier, by emitting location lists. But for existing code, and non-dwarf2 targets, I think we could do better than we do now. Here's a possible approach. We'd need a gdbarch method describing where incoming arguments were placed. This could be unified with the function calling code - cleanest might be to implement a proper "location" data type and then have the code return a list of locations to either store the parameters or fetch them depending on context. Then, we'd need a modified sort of prologue analyzer that told us whether the incoming location for a particular parameter was likely still valid, or whether the debug-info-provided location had been initialized. With enough architecture-independent support code, instead of cramming it all into the backend, I think this would not be terribly complicated either. Then, when we arrive at a function - from the very first instruction - we can display arguments correctly. The user doesn't have to worry about the copy. How does that sound? Pipe dream? Although it sounds plausible I think it's something we should revisit when GDB actually supports "locations" properly. In the mean time, we really should strive for some consistency in where we put function breakpoints. What do you think about my statement that too early is better than to late? Mark