From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28505 invoked by alias); 17 Sep 2008 15:55:05 -0000 Received: (qmail 28492 invoked by uid 22791); 17 Sep 2008 15:55:04 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 17 Sep 2008 15:54:29 +0000 Received: (qmail 25721 invoked from network); 17 Sep 2008 15:54:23 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Sep 2008 15:54:23 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] Fix a crash on NULL event_thread Date: Wed, 17 Sep 2008 15:55:00 -0000 User-Agent: KMail/1.9.9 Cc: Jan Kratochvil References: <20080912221227.GA5848@host0.dyn.jankratochvil.net> <200809122344.55797.pedro@codesourcery.com> <20080915185627.GA25128@host0.dyn.jankratochvil.net> In-Reply-To: <20080915185627.GA25128@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200809171654.39206.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00371.txt.bz2 Hi Jan, sorry for the delay, On Monday 15 September 2008 19:56:27, Jan Kratochvil wrote: > > Would it be possible to add the thread to the thread list, in > > addition to the lwp? > > IMO the reason for two lists is that really these two resources are > different. You can perfectly have tracked LWPs with no corresponding thre= ad > structures. Attached a testcase using clone(2) which if you CTRL-C it has= a > state: (gdb) plist thread_list ptid > $1 =3D {pid =3D 25112, lwp =3D 25112, tid =3D 0} > (gdb) plist lwp_list ptid > $2 =3D {pid =3D 25112, lwp =3D 25115, tid =3D 0} > $3 =3D {pid =3D 25112, lwp =3D 25112, tid =3D 0} > > New thread notification will come from libthread_db but some time in > between we have no corresponding thread structures such as they will never > exist for standalone LWPs. I understand the difference between LWPs and pthread threads. A posix threads library hides the underlying threads implementation, but that doesn't mean that we can only call "threads", things that are visible through pthreads. That is, in your non-pthreads example, you're happy to call new lwps "threads", and use CLONE_*THREAD*. =46rom GDB's perspective, a "thread" is an abstraction that represents a locus of execution. It doesn't really matter if its comes from pthreads or using CLONE_THREAD directly. You'll still need to be able to see them in "info threads", and switch between them with "thread", and GDB will have to manage thread stepping state in them. In fact, the new_thread_event thing is calling "add_thread" on an LWP, that hasn't hit a thread create event breakpoint yet. So, we're talking about *when/where* to call add_thread. In your clone-thread.c example, just put a break on child_func and let it hit to reliably trigger the new_thread_event path. I've been cooking some ideas about decoupling where we trigger the [New Thread ...] notifications (currently in add_thread), from managing the data structures, and about making GDB's core not so agnostic of 1:1, M:N, x:y, target/thread/lwp/process child/parent relations, but those will come later. In the mean time, your patch preserves the old behaviour, and looks good to me. You'll need someone else to approve it, though. --=20 Pedro Alves