Re: [PATCH 18/18] document the new VxWorks port

Jerome Guitton
2011-02-25T11:27:04Z

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.