This is the mail archive of the archer@sourceware.org mailing list for the Archer 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: Q: multiple inferiors, all-stop && vCont


On 07/21, Roland McGrath wrote:
>
> > I am trying to undestand what ugdb should know about the multiple
> > inferiors. Looks like, I shouldn't worry at all. They do not exist
> > from gdbserver's pov. It should handle the multiple attach/detach,
> > of course, but that is all. Say, qsThreadInfo should list all
> > attached threads in random order. IOW, there is no any command
> > which can refer to any particular inferior somehow, explicitly or
> > implicitly. Only THREAD-ID can matter.
>
> I'm not sure what the story on gdb's multi-process support is and how that
> relates to remote protocol details.  It's fine to start out by only
> worrying about being attached to a single process with all its threads.
> Certainly we want to be handling multiple processes well at some point, so
> don't structure things so it would be especially difficult.  But it is
> probably the case that representing that notion on the remote protocol is
> all a bit of a muddle, and you shouldn't worry about resolving that before
> moving ahead.
>
> > So. Reference to actual practice doesn't help, I suspect it is buggy.
>
> Well, actual practice of rarely-used features, anyway.
> Multi-process is newfangled and apparently quite unreliable.
> Single-process, multi-thread is what is used a lot.

OK. I'll try to send something more or less working on Monday.

I guess, non-stop mode is more interesting/important than all-stop.

Oleg.


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