This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Report the main thread.
> From: Pedro Alves <email@example.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.