[PATCH 1/8] gdb/fileio: fix errno for packets where an attachment is expected

[Andrew Burgess <aburgess@redhat.com>]

In remote.c lives remote_target::remote_hostio_send_command(), which
is used to handle sending a fileio packet to the remote, and for
parsing the reply packet.

Some commands, e.g. open, pwrite, close, send some arguments to the
remote, and then get back a single integer return value.

Other commands though, e.g. pread, readlink, fstat, send some
arguments and get back an integer return value and some additional
data.  This additional data is called the attachment.

Except, we only get the attachment if the command completes
successfully.  For example, calling readlink with a non existent path
will result in a return packet: 'F-1,2' with no attachment.  This is
as expected.

Within remote_hostio_send_command we call remote_hostio_parse_result,
this parses the status code (-1 in our example above) and
then parses the errno value (2 in our example above).

Back in remote_hostio_parse_result we then hit this block:

  /* Make sure we saw an attachment if and only if we expected one.  */
  if ((attachment_tmp == NULL && attachment != NULL)
      || (attachment_tmp != NULL && attachment == NULL))
    {
      *remote_errno = FILEIO_EINVAL;
      return -1;
    }

Which ensures that commands that expect an attachment, got an
attachment.

The problem is, we'll only get an attachment if the command
succeeded.  If it didn't, then there is no attachment, and that is as
expected.

As remote_hostio_parse_result always sets the returned error number to
FILEIO_SUCCESS unless the packet contained an actual error
number (e.g. 2 in our example above), I suggest we should return early
if remote_hostio_parse_result indicates an error packet.

I ran into this issue while working on another patch.  In that patch I
was checking the error code returned by a remote readlink call and
spotted that when I passed an invalid path I got EINVAL instead of
ENOENT.  This patch fixes this issue.

Unfortunately the patch I was working on evolved, and my need to check
the error code went away, and so, right now, I have no way to reveal
this bug.  But I think this is an obviously correct fix, and worth
merging even without a test.
---
 gdb/remote.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gdb/remote.c b/gdb/remote.c
index 349bc8cf005..241803ab2b3 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -12663,6 +12663,9 @@ remote_target::remote_hostio_send_command (int command_bytes, int which_packet,
       return -1;
     }
 
+  if (*remote_errno != FILEIO_SUCCESS)
+    return -1;
+
   /* Make sure we saw an attachment if and only if we expected one.  */
   if ((attachment_tmp == NULL && attachment != NULL)
       || (attachment_tmp != NULL && attachment == NULL))
-- 
2.25.4