Re: [patch] Suggest newer gdbserver if it has no qXfer:exec-file:read

[Pedro Alves <palves at redhat dot com>]

On 03/23/2016 09:15 PM, Jan Kratochvil wrote:
> On Tue, 22 Mar 2016 14:56:46 +0100, Pedro Alves wrote:

>> - I think the important points are:
>>
>>   - The user did not specify the executable manually.
>>
>>   - The target/server does not support automatic executable
>>     retrieval. 
>>
>> - I see that at least the following choices to correct the situation:
>>
>>   #1 - Upgrade server to some version that supports automatic automatic
>>        executable retrieval.
>>
>>   #2 - Hack on stub/server yourself to add support for automatic 
>>        executable retrieval, if possible on the target.
>>
>>   #3 - Use the "file" command.
>>
>> If you're connecting with a new gdb to an older gdbserver, it usually
>> means that installing a newer gdbserver is more than a couple
>> seconds work, and may not even be possible.  I think #3 will be the
>> path most often taken.
>>
>> So I'd suggest:
>>
>>    warning: No executable has been specified and target does not support
>>    determining executable automatically.  Try using the \"file\" command.
>>
>> Seeing this, users that can hack on a remote stub will probably
>> realize that there's now some way for gdb to automatically retrieve
>> the executable.  We don't need to expose implementation details for those
>> users; they'll be savvy enough to find the necessary info in the RSP
>> manual.  For other users, talking about implementation details may
>> largely be noise.
> 
> I still do not see there any hint that a newer FSF gdbserver would also fix the
> problem.

That's because I don't think it's a good approach.  If we followed
that direction going forward, we'd end up with:

 warning: Remote gdbserver does not support determining executable automatically.
 FSF gdbserver version 7.10 or later would support that.
 warning: Remote gdbserver does not support foo.
 FSF gdbserver version 6.5 or later would support that.
 warning: Remote gdbserver does not support bar.
 FSF gdbserver version 6.8 or later would support that.

Old version numbers shown on purpose -- that's what 7.10
will feel like in a couple years.  I think it's not a good
idea to show version numbers, nor am I convinced mentioning
gdbserver is a good idea either.  There's bare metal targets, and
then there's also other servers like qemu, Valgrind, RR, etc.

Sorry for pushing back, but I think warnings should be centered
on features, not tools and versions.

> Attached patch prints messages as:
> 
> Remote debugging using :1234
> warning: Remote gdbserver does not support determining executable automatically.
> FSF gdbserver version 7.10 or later would support that.
> warning: No executable has been specified and target does not support
> determining executable automatically.  Try using the "file" command.
> warning: Could not load vsyscall page because no executable was specified
> 0x00007ffff7ddcc80 in ?? ()
> (gdb) _
> 



> diff --git a/gdb/exec.c b/gdb/exec.c
> index 90811c0..a10ab9b 100644
> --- a/gdb/exec.c
> +++ b/gdb/exec.c
> @@ -151,7 +151,13 @@ exec_file_locate_attach (int pid, int from_tty)
>    /* Try to determine a filename from the process itself.  */
>    exec_file = target_pid_to_exec_file (pid);
>    if (exec_file == NULL)
> -    return;
> +    {
> +      warning (_("No executable has been specified and target does not "
> +		 "support\n"
> +		 "determining executable automatically.  "
> +		 "Try using the \"file\" command."));
> +      return;
> +    }

This bit is OK.

> diff --git a/gdb/symfile-mem.c b/gdb/symfile-mem.c
> index 8eb5176..79739a6 100644
> --- a/gdb/symfile-mem.c
> +++ b/gdb/symfile-mem.c
> @@ -214,8 +214,7 @@ add_vsyscall_page (struct target_ops *target, int from_tty)
>  	  format should fix this.  */
>  	{
>  	  warning (_("Could not load vsyscall page "
> -		     "because no executable was specified\n"
> -		     "try using the \"file\" command first."));
> +		     "because no executable was specified"));
>  	  return;

This bit is OK.  Please split them out and push them.

Please don't push the other hunks in.  I think we'll need more
discussion on those and I'd rather if we found some other way
to address this, if we must.

Thanks,
Pedro Alves