Re: [RFA] Report the main thread.

[Pedro Alves <pedro at codesourcery dot com>]

A Sunday 27 April 2008 16:47:42, Mark Kettenis wrote:
> > 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.
>

True, but we're talking about a GDB thread id, which is made by GDB, not
by the thread library.  It is on the same arbitrary level as the
thread library coming up with a thread id for the "main thread" in
a MT app.

> 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.
>

I don't know what complication is this.

> We do populate the threads lists for multi-threaded applications that
> have only one thread running.
>

Exactly, and that is confusing, and unconsistent.  The main thread is
not pthread_create'd (or equivalent), yet it is listed as a thread.

> > > 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.
>

I can ask GDB because GDB is providing an abstraction.

> 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.  

That is new to me, and seems to be depending on a thread library
implementation detail.  What if the thread library doesn't report
the main thread first when GDB queries the thread list?

> 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.

When we attach to a ST app, we'll add the thread that
had the stop event to the thread list -- that will be always the
"main thread" by definition.  If we're attaching to a MT app, the
thread that got the event will still exist, of course, otherwise
it wouldn't report the event, so we can add it.  Then we query the
thread library for the rest of the threads -- we never add a ptid
to the thread list if it is already listed.  If the main thread is
gone, then it  won't be the thread that reports the SIGSTOP, and
it won't the returned by the thread library.

-- 
Pedro Alves