From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29114 invoked by alias); 27 Apr 2008 15:50:41 -0000 Received: (qmail 29106 invoked by uid 22791); 27 Apr 2008 15:50:41 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 27 Apr 2008 15:50:23 +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.1) with ESMTP id m3RFlg6d010462; Sun, 27 Apr 2008 17:47:43 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id m3RFlgfc014771; Sun, 27 Apr 2008 17:47:42 +0200 (CEST) Date: Sun, 27 Apr 2008 21:46:00 -0000 Message-Id: <200804271547.m3RFlgfc014771@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: pedro@codesourcery.com CC: gdb-patches@sourceware.org, mark.kettenis@xs4all.nl, drow@false.org, nickrob@snap.net.nz, vladimir@codesourcery.com In-reply-to: <200804271603.27832.pedro@codesourcery.com> (message from Pedro Alves on Sun, 27 Apr 2008 16:03:27 +0100) Subject: Re: [RFA] Report the main thread. References: <200804262005.18646.vladimir@codesourcery.com> <20080427135246.GA9333@caradoc.them.org> <200804271422.m3REMxVF009472@brahms.sibelius.xs4all.nl> <200804271603.27832.pedro@codesourcery.com> 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-04/txt/msg00624.txt.bz2 > From: Pedro Alves > Date: Sun, 27 Apr 2008 16:03:27 +0100 > > A Sunday 27 April 2008 15:22:59, Mark Kettenis wrote: > > > Seriously though, in GDB we've always only populated the threads list > > if a program actually has threads. > > Would that be true if threads had been implemented in GDB from the > ground up, instead of being an afterthought? Hard to tell. But things like the application thread ID are simply not defined for programs that are not linked with a threads library. Not showing anything in response to the "info threads" command for non-threaded applications has been quite a conscious decision. We don't want to confront users with the complication of threads if they don't need it. We do populate the threads lists for multi-threaded applications that have only one thread running. > > An MI client will have to deal > > with that fact. If it insists on providing a threaded view of the > > world, it needs to fake up a main thread. Since it already has to do > > that for non-threaded programs, why would having a false thread create > > event for the main thread help? > > If a command is defined to take --thread=$gdb_thread_id as a parameter, > it is awkward for the frontend to have to do something different > on single-threaded apps. E.g., no --thread parameter means all > threads, or the main thread in ST apps? Well, there is no main thread in a non-threaded application; it isn't threaded, you can't ask the program for some sort of thread ID. Specifying a --thread parameter for such applications doesn't make sense, because issuing such a command means that the front-end (and probably the user) thinks the application is multi-threaded when it really isn't. I would consider it completely reasonable for gdb to warn about this. > A GDB thread id is also what can be made constant even though > the ptid of the main thread may change due to loading > thread support. Well, the GDB thread IDs depend on the order in which the threads are created. I suppose GDB will always see the main thread of a threaded applicatication first if you start it from GDB, but what if you attach GDB to an existing process? The main thread at that point might not even exist anymore.