This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Report the main thread.


> From: Pedro Alves <pedro@codesourcery.com>
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]