From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12257 invoked by alias); 7 Aug 2004 18:42:18 -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 12246 invoked from network); 7 Aug 2004 18:42:17 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 7 Aug 2004 18:42:17 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BtW91-0005hS-NN; Sat, 07 Aug 2004 14:42:15 -0400 Date: Sat, 07 Aug 2004 18:42:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: RFA: assert that target_fetch_registers did its job Message-ID: <20040807184215.GA21818@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jim Blandy , gdb-patches@sources.redhat.com References: <20040724004433.GA15591@nevyn.them.org> <410F86B4.3040500@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <410F86B4.3040500@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-08/txt/msg00214.txt.bz2 On Tue, Aug 03, 2004 at 08:36:04AM -0400, Andrew Cagney wrote: > >On Fri, Jul 23, 2004 at 05:59:11PM -0500, Jim Blandy wrote: > >>>But thread_db_fetch_registers doesn't follow that assumption. In the > >>>threaded case, given any register number, it fetches the gprs, and the > >>>fprs, supplies them, and assumes its job is done. It seems to me it > >>>sholud be calling register_valid_p (current_regcache, regno) to check > >>>that the register's value has really been supplied, and complaining if > >>>it hasn't. > > > > > >I suggest we slay thread_db_fetch_registers. > > > >Once upon a time, it served a purpose. Now it is nothing but a source > >of problems. We could pass opaque cookies rather than register data > >through the gregset structure - the interface doesn't really support > >this but at least two of the five thread-db implementations I'm aware > >of would. Or we could just give up, use thread-db for nothing besides > >finding new threads, and ask the LWP for its registers directly without > >six or eight call frames of indirection. > > You're saying have GNU/Linux thread_db_fetch_regsters bypass libthread-db? > > The thread-db can certainly take the shortest path to the registers. > However, I'm not so sure about core GDB doing the bypass - it would > violate the separation of thread and lwp (what little there is). Everything I suggested in that paragraph was intended to live in the GNU/Linux thread-db support, not in GDB core. For GNU/Linux, maintaining the politely broken fiction that one thread and one LWP are not equivalent is not worthwhile any more. Is there even a thread/lwp separation in GDB core? My understanding was that the core should never see anything having to do with an LWP; at least the trivial LWP == thread mapping should have taken place somewhere, and GDB should just talk to the threads. -- Daniel Jacobowitz