gdbserver: add vFile:lstat packet support

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.

In the previous commit I fixed the naming within GDB, renaming 'stat'
to 'lstat' throughout.

However, in order to support target_fileio_stat (as was) on remote
targets, the above patches added the vFile:stat packet, which actually
performed an 'lstat' call.  This is really quite unfortunate, and I'd
like to do as much as I can to try and clean up this mess.  But I'm
mindful that changing packets is not really the done thing.

So, this commit doesn't change anything.

Instead, this commit adds vFile:lstat as a new packet.

Currently, this packet is handled identically as vFile:stat, the
packet performs an 'lstat' call.

I then update GDB to send the new vFile:lstat instead of vFile:stat
for the remote_target::fileio_lstat implementation.

After this commit GDB will never send the vFile:stat packet.

However, I have retained the 'set remote hostio-stat-packet' control
flag, just in case someone was trying to set this somewhere.

Then there's one test in the testsuite which used to disable the
vFile:stat packet, that test is updated to now disable vFile:lstat.

There's a new test that does a more direct test of vFile:lstat.  This
new test can be extended to also test vFile:stat, but that is left for
the next commit.

And so, after this commit, GDB sends the new vFile:lstat packet in
order to implement target_ops::fileio_lstat.  The new packet is more
clearly documented than vFile:stat is.  But critically, this change
doesn't risk breaking any other clients or servers that implement
GDB's remote protocol.

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

0 files changed, 0 insertions, 0 deletions