From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32747 invoked by alias); 23 Aug 2002 20:10:23 -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 32740 invoked from network); 23 Aug 2002 20:10:21 -0000 Received: from unknown (HELO TheWorld.com) (199.172.62.106) by sources.redhat.com with SMTP; 23 Aug 2002 20:10:21 -0000 Received: from shell.TheWorld.com (root@shell01.TheWorld.com [199.172.62.241]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id QAA16093; Fri, 23 Aug 2002 16:10:18 -0400 Received: from localhost (qqi@localhost) by shell.TheWorld.com (8.9.3/8.9.3) with ESMTP id QAA80905929; Fri, 23 Aug 2002 16:10:17 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: qqi owned process doing -bs Date: Fri, 23 Aug 2002 13:10:00 -0000 From: Quality Quorum To: Andrew Cagney cc: Daniel Jacobowitz , Subject: Re: RFC: Two small remote protocol extensions In-Reply-To: <3D668F6E.6070809@ges.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-08/txt/msg00306.txt.bz2 On Fri, 23 Aug 2002, Andrew Cagney wrote: > > >> > ????? Memory is shared between threads, isn't it so ???? > > > > This is yet another long overdue problem (I had hope it was fixed in > > recent releases) - gdb lumps together mult-process > > debugging with multi-tread debugging and it it does not > > excell in any of them. > > You mean GNU/Linux? > > > It seems to me that we have to handle multi-process debugging a-la > > vxWorks with a separate gdb instance per process and thus forget about it. > > I guess you didn't mean GNU/Linux. > > The GNU/Linux and Solaris thread implementation have a specific thread > that they use when doing memory operations. That behavour should > certainly be extended across the remote protocol so that a remote server > can more exactly mimic the behavour of a native GDB. GDB's view of the > target's address space is defined by what the target's process can see. > If the target's process can't see it, neither can GDB. > > Should it be defined by ``Hg'' I guess that open to debate (current > implementation doesn't do anything here). However, I think it should be > well defined. > > > 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. > > Andrew > > Thanks, Aleksey