[PATCH v2 00/24] Multi-target support

[Pedro Alves]

On 10/20/19 12:41 PM, Philippe Waroquiers wrote:
> I played a little bit with the patch and valgrind
> (I had to apply the patch with git am --3way, otherwise it failed to apply).

Guess you missed that this was in the users/palves/multi-target-v2 branch.  :-/

> No problem encountered when playing with the result.
> I also re-read the documentation (as I forgot about how this was all
> working), and it was all pretty clear.

That's great to hear.

> 
> 3 notes:
>   * It might be interesting to one day add
>      something like 'inferior apply all/list of inferiors SOMMECOMMAND'

Agreed.

>   * when having 2 inferiors connected to 2 different valgrind gdbservers,
>     I could continue both inferiors by using 'continue&',
>     but I had to (artificially) issue 'interrupt' in the second inferior
>     to have GDB accepting 'continue&'.  So, this might be the indication
>     of a status 'running' which should be maintained per inferior,
>     while it might now be maintained globally.

I've tried to debug this a little, but I'd like to punt for now.  The error
I'm seeing first comes from a breakpoint re-set, where gdb tries to
read memory from the valgrind that is running.  Breakpoint re-sets currently
are too dumb and re-set all locations, instead of only adding/removing
the locations necessary.  And then that is running into the fact that
the remote protocol in the old all-stop mode (which is what valgrind supports)
is synchronous, gdb can't talk to the remote target until the target
reports a stop.

These sorts of issues is why I required that the remote backends
support non-stop mode for this initial pass.  I'd rather not have to fix
all these issues before landing the initial multi-target support, even
if we know there are issues we need to fix to make it cope better with
all-stop-only targets.

>   * I was (again?) confused by add-inferior silently ignoring abbreviations
>     (or more generally anything starting with - unless matching exactly
>      an option).
>     Waiting for option framework to be extended, the add-inferior command
>     could use the below that accepts abbreviations and does not ignore
>     wrong options.

Yes, that is fine with me.

Thanks,
Pedro Alves