Re: [PATCH 0/7] Do not require "file" commands for remote targets

Pedro Alves
2015-04-15T12:16:28Z

On 04/15/2015 01:02 PM, Gary Benson wrote:
> Pedro Alves wrote:
>> On 04/01/2015 12:22 PM, Gary Benson wrote:
>>> Patch 7 causes GDB to attempt to locate and open the executable
>>> in remote-target cases without multiprocess extensions:
>>
>> Should be "with multiprocess extensions". Without those, we don't
>> know the target's pid, and thus can't use pid-to-exec-file.
>
> How about:
>
> Patch 7 causes GDB to attempt to locate and open the executable
> for remote targets not using extended-remote:

That's better.

Though it affects extended-remote just the same. E.g.,:

$ gdbserver --multi :9999 /bin/sh
...

(gdb) target extended-remote :9999
...
Reading symbols from target:/bin/bash...

Or without passing a binary to gdbserver:

$ gdbserver --multi :9999
...

(gdb) target extended-remote :9999
...
(gdb) set remote exec-file /bin/sh
...
(gdb) run
...
(gdb) disconnect
(gdb) quit

now reconnect in extended-remote with another gdb instance:

$ gdb
...
(gdb) target extended-remote :9999
...
Reading symbols from target:/bin/bash...

So even more correct even would be to say that patch 7 causes GDB
to attempt to locate and open the executable of processes already
being debugged by the remote target, on initial connection,
with the simplest example being:

bash$ gdb -q
(gdb) target remote | gdbserver - /bin/sh
Remote debugging using | gdbserver - /bin/sh
Process /bin/sh created; pid = 32166
stdin/stdout redirected
Remote debugging using stdio
Reading symbols from target:/bin/bash...

Thanks,
Pedro Alves