[patch] Suggest newer gdbserver if it has no qXfer:exec-file:read
Pedro Alves
palves@redhat.com
Tue Apr 5 16:32:00 GMT 2016
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
More information about the Gdb-patches
mailing list