From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19068 invoked by alias); 5 Mar 2005 20:20:35 -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 19040 invoked from network); 5 Mar 2005 20:20:29 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 5 Mar 2005 20:20:29 -0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1D7flK-0003zK-Nu; Sat, 05 Mar 2005 15:20:34 -0500 Date: Sat, 05 Mar 2005 20:20:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] New GDB target iq2000 Message-ID: <20050305202034.GA15313@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sources.redhat.com References: <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> <200503052017.j25KHjOK016915@elgar.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503052017.j25KHjOK016915@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00066.txt.bz2 On Sat, Mar 05, 2005 at 09:17:45PM +0100, Mark Kettenis wrote: > 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. Trivial, even in the existing framework - ask the disassembler. A complete GDB port may not have a simulator, let alone my hypothetical uber-simulator, but it will definitely have a disassembler. > > 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. Well, it makes sense to me. It's clear that the FRV and submitted iq2000 ports have different heuristics for these two cases; it would be good to cover both of them in common code. -- Daniel Jacobowitz CodeSourcery, LLC