From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10252 invoked by alias); 28 Aug 2002 15:31: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 10235 invoked from network); 28 Aug 2002 15:31:26 -0000 Received: from unknown (HELO TheWorld.com) (199.172.62.105) by sources.redhat.com with SMTP; 28 Aug 2002 15:31:26 -0000 Received: from shell.TheWorld.com (tryanc@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id LAA21597; Wed, 28 Aug 2002 11:31:25 -0400 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id LAA116988200; Wed, 28 Aug 2002 11:31:25 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Wed, 28 Aug 2002 08:31:00 -0000 From: Quality Quorum To: Andrew Cagney cc: Daniel Jacobowitz , Subject: Re: RFC: Two small remote protocol extensions In-Reply-To: <3D6C41FB.4010603@ges.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-08/txt/msg00379.txt.bz2 On Tue, 27 Aug 2002, Andrew Cagney wrote: > > >> > When reading or writing memory, gdb specifies a thread. If it turns out > > > >> >> that the thread disappeared, GDB picks a thread, any thread (the > >> >> assumption being that all address spaces are pretty much similar). > >> >> > >> >> Mind you, I've seen thread implementations that implemented per-thread > >> >> local data using VM. > > > >> > > >> > > >> > 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 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. > Andrew > > Thanks, Aleksey