From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7506 invoked by alias); 11 Oct 2004 19:40:36 -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 7499 invoked from network); 11 Oct 2004 19:40:35 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 11 Oct 2004 19:40:35 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id i9BJeQW6009119; Mon, 11 Oct 2004 21:40:26 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id i9BJeQ2j001167; Mon, 11 Oct 2004 21:40:26 +0200 (CEST) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id i9BJeQU2001164; Mon, 11 Oct 2004 21:40:26 +0200 (CEST) Date: Mon, 11 Oct 2004 19:40:00 -0000 Message-Id: <200410111940.i9BJeQU2001164@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: cagney@gnu.org CC: drow@false.org, gdb-patches@sources.redhat.com, msnyder@redhat.com In-reply-to: <416AA623.7080304@gnu.org> (message from Andrew Cagney on Mon, 11 Oct 2004 11:26:27 -0400) Subject: Re: [rfa] Include the LWP in thread-db's PTIDs References: <20041010213630.GA8218@nevyn.them.org> <416AA623.7080304@gnu.org> X-SW-Source: 2004-10/txt/msg00201.txt.bz2 Date: Mon, 11 Oct 2004 11:26:27 -0400 From: Andrew Cagney > At one time, I believe that thread-db.c was planned to support > the full range of features supported by the libthread_db > interface, presumably as defined by Sun's implementation. That > never panned out, and while non-1:1 support did work at one > point, I don't think it has in a long while. If it was wanted, I > wouldn't re-implement it the same way. So this patch begins the > process of removing unneeded generality from thread-db. In > particular, while thread-db will still compute the TID, the > mapping of threads to LWPs will be considered fixed. I think assuming 1:1 threads is fair enough. But Daniel, if you're going to do that, I'd like to ask you to rename thread-db.c into linux-thread.c or something like that. Anyway, in that case I think linux-thread.c should be a fairly lightweight layer around the normal Linux LWP-aware inf-ptrace.c-derived target vector. Only use it to provide an LWP <-> TID mapping, and perhaps an initial list of LWPs to attach, but nothing else. The normal Linux target vector should in no way be dependent on it, such that it allows alternative threads strata on top of it. Something else just would be a bad design. Hmm, I guess I'm just re-stating Andrew's points here. JeffJ's been in a constant fight with that one. That's because we try to support every combination of a broken glibc and a broken kernel that we can find out there. Well, perhaps not every possible combination, but certainly some broken combinations. Reliable threads-debugging requires reliable reporting of thread/LWP exits. Otherwise we keep having problems with threads disappearing from beneath us, leaving us poking at nonexistent memory and registers. I think we should ditch most of the buggy combinations and state that Linux threads debugging will only work reliably on Linux x.y.z or later with glibc a.b.c or later. Mark