From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17544 invoked by alias); 5 Mar 2005 20:18:00 -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 17475 invoked from network); 5 Mar 2005 20:17:53 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 5 Mar 2005 20:17:53 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j25KHkEt006087; Sat, 5 Mar 2005 21:17:46 +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 j25KHkqp016918; Sat, 5 Mar 2005 21:17:46 +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 j25KHjOK016915; Sat, 5 Mar 2005 21:17:45 +0100 (CET) Date: Sat, 05 Mar 2005 20:18:00 -0000 Message-Id: <200503052017.j25KHjOK016915@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sources.redhat.com In-reply-to: <20050305193739.GA13304@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 5 Mar 2005 14:37:39 -0500) Subject: Re: [RFA] New GDB target iq2000 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> <20050305193739.GA13304@nevyn.them.org> X-SW-Source: 2005-03/txt/msg00065.txt.bz2 Date: Sat, 5 Mar 2005 14:37:39 -0500 From: Daniel Jacobowitz > 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? Makes it difficult to ignore instructions; GDB has to know the length of them in order to skip them. 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. Yikes! Well if it helps... > 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? Yup. Although the lower-limit for first-line breakpoints may cause bogus parameter values to be printed. I consider that less a problem than my program unexpectedly running to completion though. The problem is that some people tend to think differently and we never reached consensus about it. Mark