From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9144 invoked by alias); 3 Jun 2003 22:30:50 -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 9127 invoked from network); 3 Jun 2003 22:30:49 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 3 Jun 2003 22:30:49 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 2A773354C; Tue, 3 Jun 2003 15:30:48 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h53MUlA22339; Tue, 3 Jun 2003 15:30:47 -0700 Date: Tue, 03 Jun 2003 22:30:00 -0000 Message-Id: <200306032230.h53MUlA22339@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Daniel Jacobowitz Cc: gdb@sources.redhat.com, libc-alpha@sources.redhat.com Subject: Re: Amusing problem in current libthread_db In-Reply-To: Daniel Jacobowitz's message of Tuesday, 3 June 2003 18:09:12 -0400 <20030603220912.GA7922@nevyn.them.org> X-Antipastobozoticataclysm: Bariumenemanilow X-SW-Source: 2003-06/txt/msg00041.txt.bz2 The reason that code is needed for linuxthreads is that the thread descriptor might be uninitialized. The main thread and the manager thread are always reported by td_ta_thr_iter. However, early on their descriptors are all zeros and so td_thr_get_info et al need to be able to cope with that. It might make more sense not to report any threads at all before they are initialized enough to report useful information. But I think that was deemed a more risky change (vs possible presumptions of old gdbs, etc) than faking the all-zeros responses in the early stages. The reason this wasn't an issue before and got changed was that the array of thread descriptors used to be in initialized data, where the first two elements were initialized nonzero to set up the the main and manager threads. Now the whole array is in uninitialized so it can go in bss and not take up space on disk; thus the main and manager threads' elements start out zero too. td_thr_get_info does a somewhat more convincing job of faking info when dealing with an uninitialized descriptor in the inferior, i.e. always just use the main thread in that case. td_thr_getgregs et al could be made to do that. Thanks, Roland