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

[Pedro Alves <palves@redhat.com>]

Closing the loop on this one:

On 03/23/2016 09:15 PM, Jan Kratochvil wrote:
> On Tue, 22 Mar 2016 14:56:46 +0100, Pedro Alves wrote:
>> - 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).
> 
> IIUC for such an embedded target without any filesystem qXfer:exec-file:read
> would need to generate a bogus filename which would be then
> recognized/accepted by vFile:open.
> 
> Sending packet: $qXfer:exec-file:read:67:0,fff#f7...Packet received: l/root/redhat/threadit
> Reading /root/redhat/threadit from remote target...
> Sending packet: $vFile:open:2f726f6f742f7265646861742f7468726561646974,0,0#7e...Packet received: F5
> Sending packet: $vFile:pread:5,3fff,0#98...Packet received: F27f8;\177ELF\002\001\001\000
> 
> Just stating that, nothing interesting.

That'd assume that there's a structured elf on the target, while on bare
metal, you don't have that; no sections, no segments, etc.  Nothing other
than unstructured raw memory, much like what the "dump memory" would
give you.

Thanks,
Pedro Alves