From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6478 invoked by alias); 28 Aug 2002 16:44:55 -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 6466 invoked from network); 28 Aug 2002 16:44:54 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 28 Aug 2002 16:44:54 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DD89F3CA5; Wed, 28 Aug 2002 12:44:53 -0400 (EDT) Message-ID: <3D6CFE05.5080502@ges.redhat.com> Date: Wed, 28 Aug 2002 09:44:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Quality Quorum Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00382.txt.bz2 > 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 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. Andrew (1) Above and beyond anything else, this is what a user wants to be fast.