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