From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5766 invoked by alias); 5 Mar 2005 19:37:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5653 invoked from network); 5 Mar 2005 19:37:34 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 5 Mar 2005 19:37:34 -0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1D7f5n-0003UI-Gj; Sat, 05 Mar 2005 14:37:39 -0500 Date: Sat, 05 Mar 2005 19:37:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New GDB target iq2000 Message-ID: <20050305193739.GA13304@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com References: <20050222114141.GA18314@cygbert.vinschen.de> <20050303173443.GD18681@nevyn.them.org> <20050304094605.GU2839@cygbert.vinschen.de> <20050304141439.GA30249@nevyn.them.org> <20050304150129.GF2839@cygbert.vinschen.de> <20050304220104.GA14522@nevyn.them.org> <200503051128.j25BSruw007318@elgar.sibelius.xs4all.nl> <20050305164451.GA8398@nevyn.them.org> <200503051813.j25IDCxt016723@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503051813.j25IDCxt016723@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00064.txt.bz2 On Sat, Mar 05, 2005 at 07:13:12PM +0100, Mark Kettenis wrote: > That's not an excuse for not trying to come up with an algorithm > that's more robust. Attached is the patch that I have sitting in my > tree. This looks like an obvious fix to me. > Could you explain why you think it should be deprecated? Bear in mind > that it's _new_ - it was derived from various similar things in tdep > files, in an attempt to commonize. > > And it was never properly tested. And there was never a coordinated > attempt to use this common code. Yes. I'm hoping to expand use of it, which will improve test coverage, and Kevin has an analysis of another problem with it which should be fixed. > > There's two things that GDB uses the guessed prologue line information > > for. One is to place an initial breakpoint, so that the arguments have > > been saved. This problem will hopefully eventually go away, with > > improved GCC -fvar-tracking - we should be able to print the arguments > > from anywhere. Someone needs to spend a little love on the compiler > > side of this. > > > > The important thing about placing the initial breakpoint, is that it > > shouldn't be placed too far into the function. In particular it > > should not end up after a branch instruction. > > Yes. I mentioned to Kevin off-list that I've been thinking about an > ideal paradigm for implementing both this and prologue scanners. What > we need is a common simulator architecture which can "describe" the > effects of instructions - enough instructions to handle prologues, at > least. A huge project for someday :-) > > That suggestion has been made more than once in the past; I don't > really consider this viable for architectures where instructions > aren't fixed length. Could you explain why that particular property makes a difference? I'm not talking about an ultra-specialized "simulator" the way that current GDB prologue analyzers work; I'm talking about most of a complete architecture simulator, with appropriate hooks to tell GDB what it wants to know. There's plenty of other ways we could use this information. Here's one I've been thinking about in particular: some instructions are "safe" to simulate on a running process, though not all. When a breakpoint covers an instruction which is "safe", we can simulate the instruction instead of having to remove the breakpoint and single-step. Huge win with threads. > Anyway, I think most problems are caused because we are trying to use > the same code for two distinct cases: (a) getting an upper limit for > the prologue end and (b) getting a lower limit for the prologue end. > Combining (a) and (b) results in having to determine the end of the > prologue exactly, which is much harder. Just checking, but first-line breakpoints should go at the lower limit and scanning until the upper limit - is that right? -- Daniel Jacobowitz CodeSourcery, LLC