From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26060 invoked by alias); 13 Oct 2004 21:16:25 -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 26045 invoked from network); 13 Oct 2004 21:16:23 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 13 Oct 2004 21:16:23 -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 i9DLG8av013591; Wed, 13 Oct 2004 23:16:08 +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 i9DLG8GL001431; Wed, 13 Oct 2004 23:16:08 +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 i9DLG50x001428; Wed, 13 Oct 2004 23:16:05 +0200 (CEST) Date: Wed, 13 Oct 2004 21:16:00 -0000 Message-Id: <200410132116.i9DLG50x001428@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: cagney@gnu.org, gdb-patches@sources.redhat.com, msnyder@redhat.com In-reply-to: <20041012133140.GB32588@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 12 Oct 2004 09:31:40 -0400) Subject: Re: [rfa] Include the LWP in thread-db's PTIDs References: <20041010213630.GA8218@nevyn.them.org> <416AA623.7080304@gnu.org> <200410111940.i9BJeQU2001164@elgar.sibelius.xs4all.nl> <20041012133140.GB32588@nevyn.them.org> X-SW-Source: 2004-10/txt/msg00234.txt.bz2 Date: Tue, 12 Oct 2004 09:31:40 -0400 From: Daniel Jacobowitz On Mon, Oct 11, 2004 at 09:40:26PM +0200, Mark Kettenis wrote: > > 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. How about glibc-thread-db.c? I'm not sure whether that's appropriate. NPTL is defenitely Linux-specific. The Hurd doesn't have a thread_db yet. I suppose that if you're going to make some Linux-specific assumptions glibc-thread-db.c isn't right. > 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. What I'm wondering is how to handle new threads. There are two options: have the kernel report them and lin-lwp report them to thread-db, and have thread-db discover them and tell lin-lwp to attach to them. The former is much nicer but see below... Agreed. If the LWP-layer could discover new LWP's without the help of a threads-layer, all possible threads layers would benefit. Anyway, I'm wondering if there should be some other method of communication between the native and thread strata (as opposed to between lin-lwp and thread_db!). I don't much want to use to_wait for this, because the assumption in the rest of GDB is that to_wait returns when all threads are stopped and I don't want to gratuitously stop all threads when we receive a creation event. But you don't have to return from to_wait upon a creation event. But we probably should if the user asks us to report new threads. The current way of printing [new thread] messages is a bit broken, since GDB doesn't always have control over the terminal. > 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. Unfortunately, thread creation events only work reliably in 2.6.x kernels. 2.4.x is still in wide enough use that I think there's value in holding on to it. Thread exit, on the other hand, works pretty reliably - there were a series of RH NPTL kernels which couldn't report it properly, but it worked fine for LinuxThreads and now it works fine for NPTL too. Thread creation is less critical than thread exit. It doesn't matter if you don't access something that's already there. It does matter if you try to access something that's no longer there. Akthough hitting a breakpoint in a thread that we don't know about yet can be a little tricky. It might be a good idea though to clearly distinguish between kernels where thread creation is reported correctly and kernels where it isn't. Mark