From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9775 invoked by alias); 17 Dec 2001 05:32: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 9217 invoked from network); 17 Dec 2001 05:30:56 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 17 Dec 2001 05:30:56 -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 VAA07517; Sun, 16 Dec 2001 21:30:51 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.9.3/8.9.3) id WAA19546; Sun, 16 Dec 2001 22:30:38 -0700 Date: Sun, 16 Dec 2001 21:32:00 -0000 From: Kevin Buettner Message-Id: <1011217053037.ZM19545@ocotillo.lan> In-Reply-To: Daniel Jacobowitz "Re: [RFA] Don't use thread_db on corefiles" (Dec 16, 8:56pm) References: <20011213114847.A17989@nevyn.them.org> <3C18FA17.6030603@cygnus.com> <20011216205642.A4358@nevyn.them.org> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: Daniel Jacobowitz , Andrew Cagney Subject: Re: [RFA] Don't use thread_db on corefiles Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2001-12/txt/msg00417.txt.bz2 On Dec 16, 8:56pm, Daniel Jacobowitz wrote: > My instinct was "there is support in corefile-specific code for > handling threads. It works just fine; use it." It's been there since > 1993. Does it have any current consumers? I think it must, since > Kevin touched it in May and mentioned some sort of regressions. I explained this in: http://sources.redhat.com/ml/gdb-patches/2001-04/msg00279.html Here's the relevant bit: In addition to the renaming of identifiers, I also performed a type analysis and introduced calls to PIDGET (which is an existing macro which extracts a pid from a combined pid/tid) in cases where a pid was needed and calls to pid_to_ptid in cases where a pid needed to be converted into one of the combined objects. I ran into two problems with the current representation: [problem one elided] - Second, I saw some regressions on Solaris due to the fact that corelow.c was storing some corefile thread identifiers in inferior_pid. On Solaris 8, more than 16 bits are needed to represent these identifiers. For this case, I introduced some #ifdefs in corelow.c which use inferior_ptid (renamed from inferior_pid) "as is" without any masking. I plan to eliminate these ifdefs as part of phase 3. (Or I could even do it as a phase 4, if desired.) [I'm wondering if there's a better place (than my patch email) to describe this sort of thing. Our current ChangeLog style doesn't really accomodate it. Also, I think adding something like the above as a comment to the code would needlessly clutter it. Is there anywhere else it could go?] Anyway, I think the above also addresses your question about current consumers. Kevin