This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Suggest newer gdbserver if it has no qXfer:exec-file:read
- From: Pedro Alves <palves at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Gary Benson <gbenson at redhat dot com>
- Date: Tue, 5 Apr 2016 17:32:05 +0100
- Subject: Re: [patch] Suggest newer gdbserver if it has no qXfer:exec-file:read
- Authentication-results: sourceware.org; auth=none
- References: <20160319201842 dot GA16540 at host1 dot jankratochvil dot net> <56F13963 dot 9040204 at redhat dot com> <20160322131604 dot GA24312 at host1 dot jankratochvil dot net> <56F14F1E dot 5010606 at redhat dot com> <20160323211547 dot GA17400 at host1 dot jankratochvil dot net>
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