From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29638 invoked by alias); 11 Dec 2004 14:53:34 -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 29598 invoked from network); 11 Dec 2004 14:53:31 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 11 Dec 2004 14:53:31 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iBBErRkP032151; Sat, 11 Dec 2004 15:53:27 +0100 (CET) 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 iBBErRc4007282; Sat, 11 Dec 2004 15:53:27 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iBBErRrG007279; Sat, 11 Dec 2004 15:53:27 +0100 (CET) Date: Sat, 11 Dec 2004 16:11:00 -0000 Message-Id: <200412111453.iBBErRrG007279@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: jjohnstn@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <20041211012838.GA27619@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 10 Dec 2004 20:28:38 -0500) Subject: Re: [RFA]: Modified Watchthreads Patch References: <41B8E16D.6070505@redhat.com> <20041210191015.GA18430@nevyn.them.org> <41BA00E1.20900@redhat.com> <20041210203729.GA7830@nevyn.them.org> <20041211012838.GA27619@nevyn.them.org> X-SW-Source: 2004-12/txt/msg00297.txt.bz2 Date: Fri, 10 Dec 2004 20:28:38 -0500 From: Daniel Jacobowitz On Fri, Dec 10, 2004 at 03:37:29PM -0500, Daniel Jacobowitz wrote: > Please fix the whitespace at the end of s390-nat.c. Otherwise, this is > approved if Ulrich is OK with the S390 bits; let's give him a chance to > comment. Let's hold off while we discuss the observers issue. Jeff, I've been thinking about this patch, and another problem occured to me. You're using a "new thread" event, but you're not iterating over threads - you're iterating over LWPs. So whether or not we want to use an observer for this action, it's in the wrong conceptual place; on recent systems we should be able to debug multi-threaded programs that do not use libpthread with some degree of success. TLS won't work, of course, since that's library-supported... but most of the rest of what libthread_db is not necessary. The code for this on the GDB side is not completely in place yet but I'm working up to it - that's one of the goals of the revamped Linux target_ops. Yes. In principle for a platform that has a 1x1 threads implementation, the only thing your threads layer should do is translating between the thread ID's the programmer sees and the lwp ID's used by the kernel. Unfortunately for Linux this isn't completely true... Mark