Re: Q: multiple inferiors, all-stop && vCont

[Oleg Nesterov <oleg at redhat dot com>]

On 07/23, Oleg Nesterov wrote:
>
> On 07/21, Roland McGrath wrote:
> >
> > 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.

No, I need more time. Hopefully one more day, may be two, I am
not sure.

The problem is not the coding itself. The problem is that almost
every step needs a lot of experiments with gdb/gdbserver/ugdb.

For example, I spent several hours trying to understand why gdb
ignores '%Stop:' notification and never sends '$vStopped', but
it does send vStopped to the real gdbserver with the same batch
file. The reason was partly my misunderstanding, but also another
bug in gdb and the timing issues.

Or vAttach in the multithreaded case. I'd say that gdbserver is just
wrong here, even if this works in practice. The first qfThreadInfo
after vAttach reports only the main thread. After the first
vCont;t:PID.-1 only the main thread is reported again. Somehow it
provokes gdb to send more 'vCont;t:PID.-1's packets, only then it
reports the new threads via Stop/vStopped.

At first I tried to mimic this behaviour, I was already totally
confused because I also had other problems with gdb - it constantly
crashed. But finally I have found that the simple approach seems to
work too.

Right now I am trying to understand why gdb doesn't use 'vCont:c'
but sends 'c' instead. And yes, I report 'vCont;c;t' to 'vCont?'.

The are some other issues with vCont which I don't understand...

And I'd say gdb crashes too often.


So. I am working. Everything goes slower than I expected. When
I have the code which more or less works - I'll send it.

I decided to take a bit different approach, we will see if it
makes sense in the longer term.

Oleg.