[7/7] Access executable from remote system when first inferior appears

  Pedro Alves wrote:
> On 04/01/2015 12:22 PM, Gary Benson wrote:
> > This commit modifies remote_add_inferior to take an extra argument
> > try_open_exec.  If this is nonzero, remote_add_inferior will
> > attempt to open this inferior's executable as the main executable
> > if no main executable is open already.  Callers are updated
> > appropriately.
> > 
> > One testcase required updating as a result of this commit.  The
> > test checked that GDB's "info files" command does not crash if no
> > main executable is open, and relied on GDB's inability to access
> > the main executable over the remote protocol.  The test was
> > updated to inhibit this new behavior.
> 
> So this is significant user-visible change too.  I think it deserves
> an example in the commit log, and a NEWS entry.  The manual should
> probably be updated to explain/mention this too.  We already mention
> something like this in the "attach" docs:
> 
>   "When you use @code{attach}, the debugger finds the program running in
>   the process first (...)"

How about these?
  

Gary Benson wrote:
> Pedro Alves wrote:
> > On 04/01/2015 12:22 PM, Gary Benson wrote:
> > > This commit modifies remote_add_inferior to take an extra argument
> > > try_open_exec.  If this is nonzero, remote_add_inferior will
> > > attempt to open this inferior's executable as the main executable
> > > if no main executable is open already.  Callers are updated
> > > appropriately.
> > > 
> > > One testcase required updating as a result of this commit.  The
> > > test checked that GDB's "info files" command does not crash if no
> > > main executable is open, and relied on GDB's inability to access
> > > the main executable over the remote protocol.  The test was
> > > updated to inhibit this new behavior.
> > 
> > So this is significant user-visible change too.  I think it deserves
> > an example in the commit log, and a NEWS entry.  The manual should
> > probably be updated to explain/mention this too.  We already mention
> > something like this in the "attach" docs:
> > 
> >   "When you use @code{attach}, the debugger finds the program running in
> >   the process first (...)"
> 
> How about these?
> 
> diff --git a/gdb/NEWS b/gdb/NEWS
> index b11a6fc..e88210f 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -36,6 +36,11 @@
>    the operating system) when starting processes remotely, and when
>    attaching to already-running local or remote processes.
>  
> +* GDB now supports automatic location and retrieval of executable
> +  files from remote targets.  Remote debugging can now be initiated
> +  using only a "target remote" or "target extended-remote" command
> +  (no "set sysroot" or "file" commands are required).
> +
>  * Python Scripting
>  
>    ** gdb.Objfile objects have a new attribute "username",
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index 964f9c4..4f9c21b 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -2531,7 +2531,8 @@ programs on bare-board targets that lack an operating system.  You must
>  also have permission to send the process a signal.
>  
>  When you use @code{attach}, the debugger finds the program running in
> -the process first by looking in the current working directory, then (if
> +the process first by querying the operating system.  If this fails,
> +@value{GDBN} looks first in the current working directory, then (if
>  the program is not found) by using the source file search path
>  (@pxref{Source Path, ,Specifying Source Directories}).  You can also use
>  the @code{file} command to load the program.  @xref{Files, ,Commands to

Also, I added this to the commit message:

  With this commit, remote debugging can now be initiated using only a
  "target remote" or "target extended-remote" command; no "set sysroot"
  or "file" commands are required, e.g.

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

Is that ok?

Cheers,
Gary
  

On 04/15/2015 02:55 PM, Gary Benson wrote:
> Pedro Alves wrote:
>> On 04/01/2015 12:22 PM, Gary Benson wrote:
>>> This commit modifies remote_add_inferior to take an extra argument
>>> try_open_exec.  If this is nonzero, remote_add_inferior will
>>> attempt to open this inferior's executable as the main executable
>>> if no main executable is open already.  Callers are updated
>>> appropriately.
>>>
>>> One testcase required updating as a result of this commit.  The
>>> test checked that GDB's "info files" command does not crash if no
>>> main executable is open, and relied on GDB's inability to access
>>> the main executable over the remote protocol.  The test was
>>> updated to inhibit this new behavior.
>>
>> So this is significant user-visible change too.  I think it deserves
>> an example in the commit log, and a NEWS entry.  The manual should
>> probably be updated to explain/mention this too.  We already mention
>> something like this in the "attach" docs:
>>
>>   "When you use @code{attach}, the debugger finds the program running in
>>   the process first (...)"
> 
> How about these?
> 
> diff --git a/gdb/NEWS b/gdb/NEWS
> index b11a6fc..e88210f 100644
> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -36,6 +36,11 @@
>    the operating system) when starting processes remotely, and when
>    attaching to already-running local or remote processes.
>  
> +* GDB now supports automatic location and retrieval of executable
> +  files from remote targets.  Remote debugging can now be initiated
> +  using only a "target remote" or "target extended-remote" command
> +  (no "set sysroot" or "file" commands are required).

LGTM, though it should probably say

  See "New remote packets" below/above.

too, to hint that this needs remote target support.  It's what we
did in the range-stepping NEWS entry, for example.

Thanks,
Pedro Alves
  

On 04/15/2015 02:55 PM, Gary Benson wrote:
> Pedro Alves wrote:
>> > On 04/01/2015 12:22 PM, Gary Benson wrote:
>>> > > This commit modifies remote_add_inferior to take an extra argument
>>> > > try_open_exec.  If this is nonzero, remote_add_inferior will
>>> > > attempt to open this inferior's executable as the main executable
>>> > > if no main executable is open already.  Callers are updated
>>> > > appropriately.
>>> > > 
>>> > > One testcase required updating as a result of this commit.  The
>>> > > test checked that GDB's "info files" command does not crash if no
>>> > > main executable is open, and relied on GDB's inability to access
>>> > > the main executable over the remote protocol.  The test was
>>> > > updated to inhibit this new behavior.
>> > 
>> > So this is significant user-visible change too.  I think it deserves
>> > an example in the commit log, and a NEWS entry.  The manual should
>> > probably be updated to explain/mention this too.  We already mention
>> > something like this in the "attach" docs:
>> > 
>> >   "When you use @code{attach}, the debugger finds the program running in
>> >   the process first (...)"
> How about these?
> 

Missed the manual bit:

>  
>    ** gdb.Objfile objects have a new attribute "username",
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index 964f9c4..4f9c21b 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -2531,7 +2531,8 @@ programs on bare-board targets that lack an operating system.  You must
>  also have permission to send the process a signal.
>  
>  When you use @code{attach}, the debugger finds the program running in
> -the process first by looking in the current working directory, then (if
> +the process first by querying the operating system.  If this fails,
> +@value{GDBN} looks first in the current working directory, then (if
>  the program is not found) by using the source file search path
>  (@pxref{Source Path, ,Specifying Source Directories}).  You can also use
>  the @code{file} command to load the program.  @xref{Files, ,Commands to

This looks right, but it's not what I was thinking.  The "attach" reference
was just to give an example of where we document that gdb find the
program for the user.  I think we should say something like that in
the "target remote" documentation too.

Thanks,
Pedro Alves
  

On 04/15/2015 03:05 PM, Gary Benson wrote:
> Also, I added this to the commit message:
> 
>   With this commit, remote debugging can now be initiated using only a
>   "target remote" or "target extended-remote" command; no "set sysroot"
>   or "file" commands are required, e.g.
> 
>     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...
> 
> Is that ok?
> 

OK.

Thanks,
Pedro Alves
  

> Date: Wed, 15 Apr 2015 14:55:55 +0100
> From: Gary Benson <gbenson@redhat.com>
> Cc: gdb-patches@sourceware.org
> 
> How about these?

Fine with me, thanks.
  

Pedro Alves wrote:
> On 04/15/2015 02:55 PM, Gary Benson wrote:
> > diff --git a/gdb/NEWS b/gdb/NEWS
> > index b11a6fc..e88210f 100644
> > --- a/gdb/NEWS
> > +++ b/gdb/NEWS
> > @@ -36,6 +36,11 @@
> >  
> > +* GDB now supports automatic location and retrieval of executable
> > +  files from remote targets.  Remote debugging can now be initiated
> > +  using only a "target remote" or "target extended-remote" command
> > +  (no "set sysroot" or "file" commands are required).
> 
> LGTM, though it should probably say
> 
>   See "New remote packets" below/above.
> 
> too, to hint that this needs remote target support.  It's what we
> did in the range-stepping NEWS entry, for example.

Ok, I added it.

Cheers,
Gary