From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10491 invoked by alias); 12 Mar 2002 03:16:37 -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 10410 invoked from network); 12 Mar 2002 03:16:33 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 12 Mar 2002 03:16:33 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id TAA21214; Mon, 11 Mar 2002 19:16:30 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.11.6/8.11.6) id g2C3GJh21459; Mon, 11 Mar 2002 20:16:19 -0700 Date: Mon, 11 Mar 2002 19:16:00 -0000 From: Kevin Buettner Message-Id: <1020312031619.ZM21458@localhost.localdomain> In-Reply-To: Daniel Jacobowitz "Re: [PATCH RFA/RFC] Don't use lwp_from_thread() in thread_db_wait()" (Mar 11, 9:47pm) References: <1020311234554.ZM20650@localhost.localdomain> <20020311214703.A462@nevyn.them.org> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Daniel Jacobowitz Subject: Re: [PATCH RFA/RFC] Don't use lwp_from_thread() in thread_db_wait() Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-03/txt/msg00174.txt.bz2 On Mar 11, 9:47pm, Daniel Jacobowitz wrote: > On Mon, Mar 11, 2002 at 04:45:54PM -0700, Kevin Buettner wrote: > > I'm seeing the following failure when I run the gdb testsuite on an > > SMP machine (GNU/Linux/x86): > > > > FAIL: gdb.threads/pthreads.exp: continue to bkpt at common_routine in thread 2 > > Thank you for investigating this! I've been seeing it somewhat > erratically for months, but not had any idea where to start. > > > thread_db_wait() wants to learn the lwp id of the thread that it > > should wait for so that it can ask the lwp layer to wait on the lwp > > corresponding to the thread in question. In order to do this, it > > calls lwp_from_thread(). lwp_from_thread needs help from the > > libthread_db.so to figure this out, so it calls td_ta_map_id2thr(). > > BUT, this libthread_db function must interrogate the inferior > > process's memory to look at the thread data structures. To do this, > > it calls back into gdb, using ps_pdread() to fetch the memory in > > question. Eventually, on Linux, ptrace() gets called to actually > > fetch the memory. > > There's another solution that I see. At the top of thread-db is the > comment: > > /* FIXME: There is certainly some room for improvements: > - Cache LWP ids. > > This would be a tremendous performance win, and fix this problem. But > that may be a slightly longer term solution. I think that an LWP id cache is only useful so long as all of the threads are stopped. This is because the mappings could change in the course of running the program. So, for this particular case, where the threads are running and we want to wait for one of them to stop, the cache wouldn't be useful to us. Of course, if we have knowledge that a particular thread implementation never changes its mappings or perhaps only changes its mappings for certain threads, we might be able to use such a cache across the stop/start transitions. However, I think that Mark had intended for thread-db.c to be a fairly generic solution that's not wedded to any one particular thread implementation. In particular, it should be possible to use it with an M:N model in which a thread may migrate from one LWP to another. That said, the LWP<->TID mapping operations are farily expensive (since they involve fairly sizable target memory reads), and I agree that an LWP cache would be beneficial even if it needs to be invalidated when the program starts again. Kevin