From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2925 invoked by alias); 3 Dec 2002 21:41:03 -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 2918 invoked from network); 3 Dec 2002 21:41:02 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 3 Dec 2002 21:41:02 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 040333E4B; Tue, 3 Dec 2002 16:40:50 -0500 (EST) Message-ID: <3DED24E1.70403@redhat.com> Date: Tue, 03 Dec 2002 13:41: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: Daniel Jacobowitz Cc: Mark Kettenis , msnyder@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [Fwd: Re: [Fwd: Re: gdb/725: Crash using debug target and regcaches (in 5.3 branch?)]] References: <3DE3F135.6030605@redhat.com> <3DE53144.3020502@redhat.com> <200211301613.gAUGDInq000267@elgar.kettenis.dyndns.org> <3DE8E9F8.5000902@redhat.com> <3DECE58A.6090001@redhat.com> <20021203171926.GA10631@nevyn.them.org> <3DED03F1.6070601@redhat.com> <20021203193322.GA19891@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00088.txt.bz2 > > It's not an assumption at this point. proc-service.c:230 to > thread_db_fetch_registers is the only path into lin_lwp_fetch_registers. > And that does: > inferior_ptid = BUILD_LWP (lwpid, ph->pid); > > So at this point we _know_ that the thread we're querying has its > registers in the LWP. That's the whole point. To just to clarify something, I'm being critical of the overall design here, not your patch. The comment is for sparc-nat.c (which also gets used on sun-4 and free bsd systems). The target/*-nat interface shouldn't be be making assumptions such as this (global state, only ever one LWP / thread active, ...). Doing so is poor design, it leads to bugs just like the one being discussed here. If, instead, the code had been correctly implemented (what 5 years ago?) this bug, and these on-going problems, wouldn't have occured. Andrew