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: [PATCH 18/18] document the new VxWorks port


Eli Zaretskii (eliz@gnu.org):

> > > > +@kindex info wtx threads
> > > > +@item info wtx threads
> > > 
> > > Why a separate command?  Isn't it possible to use "info threads"?
> > 
> > "info threads" lists only the threads of the inferior, whereas
> > "info wtx threads" lists all threads on target.
> 
> Since there's no "inferior" on this target, is it so bad to show all
> the threads?
> 
> And what does "info threads" do on that target?

It depends. In single-task mode, it displays only the thread being
debugged. In multi-tasks mode, it displays the list of threads that
have been created by a given kernel module.

In both cases, "info threads" actually displays the threads that we
are debugging (e.g. that are stopped when a breakpoint is reached);
whereas "info wtx threads" displays any task running on kernel space
(even those that that are not being debugged).


> > The reason why it is not called, say, "info wtx processes", is a
> > particularity of VxWorks: most applications actually run on kernel
> > space, and share the same memory area. So they are really threads, not
> > processes.
> 
> That's fine, but then why not treat them as threads?

Well, the thing is that we have a sort of emulation of "processes"
(I'd guess that the concept of "thread group" would actually be a
better fit here) in multi-tasks mode. So we need to have a distinction
between the threads that are of interest for the debugger and the ones
that just happen to run on the same memory space.


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