RE: multiple live inferiors

["taylor, david" <david.taylor@emc.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3327 bytes --]

> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Thursday, August 11, 2016 11:22 AM
> 
> On 08/11/2016 03:56 PM, taylor, david wrote:
> > Currently GDB supports having multiple non-live inferiors.  But, if I try to
> > add a second live inferior it wants to kill the current live inferior.
> 
> By "non-live", I assume you mean file_stratum inferiors
> (executable files, etc.).  GDB does not support having multiple
> core dump inferiors loaded.

I wasn't  thinking about core files and was unaware of that limitation.  I don't
currently have a need for multiple core dump inferiors.

I was thinking of non-live as targets for which target_has_execution returns false.

> 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.

> 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).

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.

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...

> > at which point GDB will say:
> >
> >     A program is being debugged already.  Kill it? (y or n)
> >
> > I'd be okay with the question if the current inferior was live.  But, it is just
> an executable.
> >
> > I assume that there's more to changing this than just modifying
> target_preopen.
> > What else is likely to break or need modification?
> 
> See here:
> 
>   https://sourceware.org/gdb/wiki/MultiTarget
> 
> Thanks,
> Pedro Alves

\x16º&ÖëzÛ«ŸŽvÛ¹b²Ö«r\x18\x1d