Re: multiple live inferiors

[Pedro Alves <palves@redhat.com>]

On 08/11/2016 06:13 PM, taylor, david wrote:
>> From: Pedro Alves [mailto:palves@redhat.com]

>> gdb _does_ however support having multiple live inferiors.  It works
>> as long as they're all behind the same target connection.  E.g.,
>> multiple inferiors with the native target.  Or
>> multiple inferiors against gdbserver.  The simplest to get them
>> is to enable following forks, with "set detach-on-fork off".
> 
> The targets involved all have different elf files.  They are running on different boards
> within our box.  Neither is the ancestor / descendant of the other.

I said the simplest, not the only way.  Different processes
running different executables is fully supported.  The loaded
"executable" is per-inferior:

 add-inferior 2
 file prog2
 set remote exec-file /path/prog2
 run

A program that forks usually execs shortly after, afterall.

> 
>> You're trying to add a second target connection, which is
>> a bit orthogonal.
> 
> 
>>> That is, I can do:
>>>
>>>     gdb some-file.elf
>>>     set non-stop on
>>>     set target-async on
>>>     target extended-remote | program with some arguments
>>
>> "program" here will be the server.
>>
>>>     add-inferior -exec new-file.elf
>>>     info inferiors
>>>     inferior 2
>>>     target extended-remote | program with different arguments
>>>
>>
>> So here replace the second "target extended-remote"
>> with "attach" or "run" to start the new inferior under
>> control of the first server.
> 
> Neither attach nor run is suitable.
> 
> The elf files are the kernels.  The model is one a single process consisting
> of a bunch of threads in a common address space.
> 
> The arguments to the program, which runs on the desktop, not the target,
> include a user name and password (used for authentication) and an IP address.
> The program establishes a TCP/IP connection to the GDB stub port on the board.
> It passes the user name and password to the box.  Once the connection is authenticated,
> the program just copies, without examination, remote protocol packets back and
> forth until the connection is broken (e.g., GDB disconnects).

The remote protocol's multi-process extensions make the remote protocol packets
carry process ids attached to thread ids, so that a single remote server can
debug more than one process.

So what people can do currently is make the server that runs on
the desktop multiplex the connections, not gdb.  Then each remote 
board is a different process.

You'd have to use a different way to specify the user/password/ip.
E.g., as program arguments, passed to "run", or using "monitor ..." commands.

So you'd first connect to the server with "target extended-remote | server"
and not be debugging anything yet.  

At this point, if the server can discover the list of remote boards itself,
you could also expose them as already-running processes that the user would
list with "info os process", and then attach to with "attach 1", etc.

Just some ideas that you'd have to bake a bit more.

> 
> There is no support for switching to a different board whether within the desktop
> program or within the GDB stub running on a board within the box.
> 
> I want to have multiple inferiors each with their own dedicated (extended-)remote target.

Can't have that today, as you've seen in that wiki page I pointed at.  I'd love to
see it happen, though.

> 
> While my current use case is for multiple boards within the same box, I can envision a future
> where the inferiors might be in different boxes in different buildings...
> 

Right.

Thanks,
Pedro Alves