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

[Pedro Alves <palves at redhat dot com>]

On 03/22/2016 01:16 PM, Jan Kratochvil wrote:
> On Tue, 22 Mar 2016 13:24:03 +0100, Pedro Alves wrote:
>> On 03/19/2016 08:18 PM, Jan Kratochvil wrote:
>>>     if (packet_support (PACKET_qXfer_exec_file) != PACKET_ENABLE)
>>> -    return NULL;
>>> +    {
>>> +      warning (_("No executable has been specified (see the \"file\" command) "
>>> +                 "and remote gdbserver does not "
>>> +		 "support packet \"qXfer:exec-file:read\""
>>> +		 " - please use FSF gdbserver version 7.10 or later."));
>>> +      return NULL;
>>> +    }
>>
>> I think this will print the warning after connecting to any
>> random stub, not just gdbserver.  Won't it be confusing
>> to suggest FSF gdbserver in that case?
> 
> (1) I think this message can only appear during a mistake.  Is it right?
> In fact this is my primary concern with this patch.
> In such case I find any info better than no info.
> 
> (2) Still it may suggest they could for example implement qXfer:exec-file:read
> in their gdbserver stub if appropriate.  I believe that people who use custom
> gdbserver stub are more aware of how to fix it than normal
> (=desktop/enterprise) OS developers who just try to debug some programs.
> 
> (3) Do you have a better idea?  One could add "if approproate" in that
> message but I find that excessive.  One could detect FSF gdbserver
> (if possible, I do not think it is, BTW it could be good to identify
> variant+version of gdbserver over the protocol) but then still if it either is
> or is not a FSF gdbserver that message may be relevant in some cases.
> 

- It's usually a mistake, though you can genuinely not have a
  binary available.  Not "only", but "usually".

- Random stubs may not know at all the executable that is running -- the
  remote end is often just bare metal raw memory, no concept of elf, etc.
  So it's not just a matter of implementing a packet - more tooling might
  and I suspect will, be necessary.  OTOH, there are OSs where it's just not
  possible, by design, to retrieve the name of the executable a process
  is running, like OpenBSD (I find it odd not to allow a ptracer access
  to that, but, alas).

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

Thinking of local/remote parity (and perhaps some day using gdbserver
for local debugging), that text is also generic enough that it could
be emitted by common code instead.

WDYT?

Thanks,
Pedro Alves