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.


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

Particularly because the "file" command is not the whole truth, plain
executable is sufficient mostly only for embedded systems.  For normal OSes
one needs also the shared libraries and those all are IMO not easy to access
without new FSF gdbserver.  But that's a whole new bug/issue:

With current FSF GDB HEAD and old FSF gdbserver I expected I could do:
	gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234' 
(supplying that unsupported qXfer:exec-file:read by "file")
But that does not work because:
	Sending packet: $vFile:setfs:0#bf...Packet received: OK
	Packet vFile:setfs (hostio-setfs) is supported
	...
	Sending packet: $vFile:setfs:104#24...Packet received: OK
	"target:/root/redhat/threadit": could not open as an executable file: Invalid argument

GDB documentation says:
	The valid responses to Host I/O packets are:
	An empty response indicates that this operation is not recognized.

OT: I do not see why "empty response" is response "OK" but apparently it is.

You can see that gdbserver above said "setfs" is unsupported but GDB
recognized it as a response gdbserver does support it.  Later
remote_hostio_set_filesystem() reports -1 as it is confused by the invalid
empty response for setfs while it sees no PACKET_DISABLE indication.
And GDB errors on it as remote_hostio_set_filesystem() returns 0 on
PACKET_DISABLE.

Are you aware of this general PACKET_DISABLE bug?  I can prepare some more
general real patch if not.

With the attached hack in packet_ok() I really can debug fine:
with unpatched old FSF gdbserver and patched FSF GDB HEAD:
	gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234' 
	Sending packet: $vFile:setfs:0#bf...Packet received: OK
	Packet vFile:setfs (hostio-setfs) is NOT supported
	...
	(gdb) info sharedlibrary 
	From                To                  Syms Read   Shared Object Library
	0x00007ffff7ddbae0  0x00007ffff7df627a  Yes (*)     target:/lib64/ld-linux-x86-64.so.2
	0x00007ffff7bc48a0  0x00007ffff7bcf514  Yes (*)     target:/lib64/libpthread.so.0


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

That's a good idea.  So we may be talking about two messages.


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) _


Thanks,
Jan