This is the mail archive of the 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.

> Date: Sun, 27 Apr 2008 09:52:46 -0400
> From: Daniel Jacobowitz <>
> On Sun, Apr 27, 2008 at 10:56:33AM +1200, Nick Roberts wrote:
> >  > > I still don't see the point in reporting the main thread.  If there's more
> >  > > than one thread the user can switch between them but what course of action
> >  > > is available with just one thread?
> >  > 
> >  > The GUI might have a thread list, for instance.
> > 
> > But my question was "what could a user do with it?".  AFAICS a thread list with
> > just one thread in it just looks like the output of the "frame" command.
> Well, for example, Eclipse's stack panel is organized as a multi-level
> list.  It's got expanding items for each debug session, thread, and
> stack frame.  So the main thread's backtrace is inside of an item
> containing the thread ID.

So Eclipse assumes that all programs are threaded?  That's so ... Java.

Seriously though, in GDB we've always only populated the threads list
if a program actually has threads.  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?

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