gdbserver: fix vFile:stat to actually use 'stat'

This commit continues the work of the previous two commits.

In the following commits I added the target_fileio_stat function, and
the target_ops::fileio_stat member function:

  * 08a115cc1c4 gdb: add target_fileio_stat, but no implementations yet
  * 3055e3d2f13 gdb: add GDB side target_ops::fileio_stat implementation
  * 6d45af96ea5 gdbserver: add gdbserver support for vFile::stat packet
  * 22836ca8859 gdb: check for multiple matching build-id files

Unfortunately I messed up, despite being called 'stat' these function
actually performed an 'lstat'.  The 'lstat' is the correct (required)
implementation, it's the naming that is wrong.

Additionally, to support remote targets, these commit added the
vFile::stat packet, which again, performed an 'lstat'.

In the previous two commits I changed the GDB code to replace 'stat'
with 'lstat' in the fileio function names.  I then added a new
vFile:lstat packet which GDB now uses instead of vFile:stat.

And that just leaves the vFile:stat packet which is, right now,
performing an 'lstat'.

Now, clearly when I wrote this code I fully intended for this packet
to perform an lstat, it's the lstat that I needed.  But now, I think,
we should "fix" vFile:stat to actually perform a 'stat'.

This is risky.  This is a change in remote protocol behaviour.

Reasons why this might be OK:

  - vFile:stat was only added in GDB 16, so it's not been "in the
    wild" for too long yet.  If we're quick, we might be able to "fix"
    this before anyone realises I messed up.

  - The documentation for vFile:stat is pretty vague.  It certainly
    doesn't explicitly say "this does an lstat".  Most implementers
    would (I think), given the name, start by assuming this should be
    a 'stat' (given the name).  Only if they ran the full GDB
    testsuite, or examined GDB's implementation, would they know to
    use lstat.

Reasons why this might not be OK:

  - Some other debug client could be connecting to gdbserver, sending
    vFile:stat and expecting to get lstat behaviour.  This would break
    after this patch.

  - Some other remote server might have implemented vFile:stat
    support, and either figured out, or copied, the lstat behaviour
    from gdbserver.  This remote server would technically be wrong
    after this commit, but as GDB no longer uses vFile:stat, then this
    will only become a problem if/when GDB or some other client starts
    to use vFile:stat in the future.

Given the vague documentation for vFile:stat, and that it was only
added in GDB 16, I think we should fix it now to perform a 'stat', and
that is what this commit does.

The change in behaviour is documented in the NEWS file.  I've improved
the vFile:stat documentation in the manual to better explain what is
expected from this packet, and I've extended the existing test to
cover vFile:stat.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

1 files changed, 10 insertions, 5 deletions

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index a564307..6139bc3 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -46730,12 +46730,16 @@ If an error occurs the return value is -1.  The format of the
 returned binary attachment is as described in @ref{struct stat}.
 
 @item vFile:stat: @var{filename}
-Get information about the file @var{filename} on the target.
-On success the information is returned as a binary attachment
-and the return value is the size of this attachment in bytes.
-If an error occurs the return value is -1.  The format of the
+Get information about the file @var{filename} on the target as if from
+a @samp{stat} call.  On success the information is returned as a binary
+attachment and the return value is the size of this attachment in
+bytes.  If an error occurs the return value is -1.  The format of the
 returned binary attachment is as described in @ref{struct stat}.
 
+If @var{filename} is a symbolic link, then the information returned is
+about the file the link refers to, this is inline with the @samp{stat}
+library call.
+
 @item vFile:lstat: @var{filename}
 Get information about the file @var{filename} on the target as if from
 an @samp{lstat} call.  On success the information is returned as a
@@ -46743,7 +46747,8 @@ binary attachment and the return value is the size of this attachment
 in bytes.  If an error occurs the return value is -1.  The format of
 the returned binary attachment is as described in @ref{struct stat}.
 
-If @var{filename} is a symbolic link, then this packet returns
+This packet is identical to @samp{vFile:stat}, except if
+@var{filename} is a symbolic link, then this packet returns
 information about the link itself, not the file that the link refers
 to, this is inline with the @samp{lstat} library call.