From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30557 invoked by alias); 24 Aug 2007 10:46:34 -0000 Received: (qmail 30536 invoked by uid 22791); 24 Aug 2007 10:46:33 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 24 Aug 2007 10:46:29 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id l7OAkO1A001932; Fri, 24 Aug 2007 12:46:24 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id l7OAkOel020079; Fri, 24 Aug 2007 12:46:24 +0200 (CEST) Date: Fri, 24 Aug 2007 10:46:00 -0000 Message-Id: <200708241046.l7OAkOel020079@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: veenu.verma@ericsson.com CC: gdb@sourceware.org In-reply-to: <9171BA436A79BF46953672FB5A11DA5E012B45C6@esealmw104.eemea.ericsson.se> (veenu.verma@ericsson.com) Subject: Re: Thread exit & create events References: <9171BA436A79BF46953672FB5A11DA5E012B45C6@esealmw104.eemea.ericsson.se> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00182.txt.bz2 > Date: Fri, 24 Aug 2007 10:51:10 +0200 > From: "Veenu Verma (AS/EAB)" > > Hello > > We are integrating GDB back end with DSF ( Debugger Services Framework ) > in Eclipse. > Found two stumbling blocks around thread exit/create events > > 1. Though GDB raises a thread exit event but -thread-list-ids command > still list the reported exited thread for quite some time. > There is a gap till I guess the thread completely exits. Only info > threads give the hint by using "Exiting" in information. > This is a problem for us as we are relying on events and thread-list-ids > commands to paint the GUI. > Info threads is used sparingly from front end. > Can -thread-list-ids command take into account the exited threads ? Is > it difficult to achieve this in GDB ? GDB will defenitely need to keep track of the thread ID until the thread is fully gone. I guess -thread-list-ids simply uses GDB's internal thread list, so exiting thread show up. And I guess there are people that actually want this, because the thread almost certainly will still show up if you look for it with the tools your operating system provides. I guess the basic issue here is at what level you want to do thread debugging. For debugging code that simply uses threads, you may want to see the thread disappear if you call pthread_exit() (or whatever function the threading library provides for terminating threads). But if you have joinable threads you may want to keep them visible until another thread has called pthread_join(). If you're debugging the threads library itself, you almost certainly want to keep the thread visible until it has actually completely stopped executing code. > 2. GDB thread identifier is not speicified when a thread is created or > exited. Only system identifier is used. > Again thread-list-ids uses only gdb thread identifier. Hence, the > mismatch and the problem. > Since on HP-UX systems gdb thread identifier is shown, I'm guessing it > shouldn't be hard to do the same for Linux. > Is there a reason for not to have gdb identifier on linux or it's just > that it's not done yet. HP-UX has a rather well thought out debugging interface for threads. That interface includes the possibility to store a thread identifier in the kernel whenever a thread is created, and the debugger can ask for that identifier. That makes it possible for GDB to always know the thread identifier. Linux doesn't have a very well thought out threads debugging interface. There is special threads debugging library that is supposed to help GDB find out things like userland thread identifiers, but there are several versions of that library out there and some of them have serious bugs. The workarounds we have for these bugs mean that there always is a period of time where we are not completely sure whether a thread is still alive or dead. During that time the thread doesn't really have a valid thread identifier so it doesn't get displayed. Something similar happens when creating a thread. When the underlying kernel thread is created GDB notices that, but it cannot yet ask the thread debugging library for the thread identifier, since the data structures describing the thread haven't been set up yet completely.