multiple live inferiors

multiple live inferiors

[taylor, david]

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.

That is, I can do:

    gdb some-file.elf
    set non-stop on
    set target-async on
    target extended-remote | program with some arguments
    add-inferior -exec new-file.elf
    info inferiors
    inferior 2
    target extended-remote | program with different arguments

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?

Thanks.

Re: multiple live inferiors

[Pedro Alves]

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.

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

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.

> 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

RE: multiple live inferiors

[taylor, david]

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

Re: multiple live inferiors

[Pedro Alves]

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