From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11344 invoked by alias); 28 Aug 2002 16:49:29 -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 11317 invoked from network); 28 Aug 2002 16:49:29 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 28 Aug 2002 16:49:29 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17k6wQ-0004i8-00; Wed, 28 Aug 2002 12:49:18 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17k61E-0000fK-00; Wed, 28 Aug 2002 12:50:12 -0400 Date: Wed, 28 Aug 2002 09:49:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Quality Quorum , gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions Message-ID: <20020828165012.GA2384@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Quality Quorum , gdb@sources.redhat.com References: <3D6CFE05.5080502@ges.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6CFE05.5080502@ges.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00383.txt.bz2 On Wed, Aug 28, 2002 at 12:44:53PM -0400, Andrew Cagney wrote: > >It does not mean that everybody else should suffer, it is time to fix > >>>> > this youthful indiscretion. > > > >>> > > > >>>> > >>>> Humor me. So who is suffering? > > > >>> > >>> > >>> All things embedded and I suppose it is a much bigger market/user group > >>> than ***ix one. > > > >> > >>Why are ``all things embedded'' suffering? > >> > >>I know of two cases: > >> > >>a) The threads have a 100% shared address space. Binding memory > >>accesses to a thread will make zero difference. > >> > >>b) The threads do not have a 100% shared address space. Binding memory > >>accesses to a thread will at least make it better reflect GDB's view of > >>a threads address space. > >> > > > > > >Forcing model (b) on underlying environment (a) will force unnecessary > >invalidations of memory cache and will pretty negatively affect > >performance of a debugging session. > > I don't believe that it is even possible to measure a cache effect when > profiling GDB's single step performance(1) --- other, far bigger, host > or host<->target things things will drown any cache effects. > > Anyway, in case (a), since GDB won't be able to detect which thread was > used to do the read --- the target is still free to use a thread, any > thread. I assume he meant GDB's dcache. Which is a real lifesaver, except when it actually slows things down. > >I would perefer to treat (b) as a separate process (and run separate gdb > >instance to debug it a-la vxWorks and normal multi process debugging), > >however, it will be fine to make this thing a configurable run time > >parameter. At the sime time of forcing (a) to emulate (b) does not seem > >appropriate. > > A target is always free to implement (b) using separate GDBs. This is certainly true. HP even has fragmented code to do it natively. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer