================
@@ -3064,22 +3064,41 @@ static int gdb_errno_to_system(int err) {
static uint64_t ParseHostIOPacketResponse(StringExtractorGDBRemote &response,
uint64_t fail_result, Status &error)
{
+ // The packet is expected to have the following format:
+ // 'F<retcode>,<errno>'
+
response.SetFilePos(0);
if (response.GetChar() != 'F')
return fail_result;
+
int32_t result = response.GetS32(-2, 16);
if (result == -2)
return fail_result;
- if (response.GetChar() == ',') {
- int result_errno = gdb_errno_to_system(response.GetS32(-1, 16));
- if (result_errno != -1)
- error = Status(result_errno, eErrorTypePOSIX);
- else
- error = Status(-1, eErrorTypeGeneric);
- } else
+
+ if (response.GetChar() != ',') {
error.Clear();
+ return result;
+ }
+
+ // Response packet should contain a error code at the end. This code
+ // corresponds either to the gdb IOFile error code, or to the posix errno.
----------------
jasonmolenda wrote:
> @jasonmolenda @DavidSpickett could you please confirm that my understanding
> is correct:
>
> 1. The error is on the lldb-server side, which have to put 9999 (EUNKNOWN) as
> error code instead of 26, so it should be fixed there.
My assumption from the gdb RSP documentation you linked to earlier is that any
constant not listed in that table cannot be expected to be handled correctly.
I don't know if the different errno numeric values are even specified by the
POSIX doc -- they're ABI on a given platform, but I bet Darwin could use 2 for
EBUSY and Linux could use 16 for EBUSY and both be compliant with the spec, so
sending the errno value from the stub to lldb would not be defined. (i'm too
lazy to actually look in the POSIX spec, but all of this needs to work on
non-POSIX environments on either side too, so we have to use the gdb RSP spec's
documented values and only those.)
> 2. If lldb client receives response packet with EUNKNOWN code I can try to
> obtain an error string from debugserver if it supports this functionality.
In lldb-server if lldb has sent `QEnableErrorStrings` to enable error strings
(v. `GDBRemoteCommunicationServer::Handle_QErrorStringEnable` /
`GDBRemoteCommunicationServer::SendErrorResponse`), then the error code and
error string (if set) will be sent to the debugger.
We should only send the errno values defined in
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Errno-Values.html#Errno-Values
but we can send any string when lldb has enabled error strings. The method
that receives the error message may not relay it up to the user right now --
but that's a purely lldb-side issue.
https://github.com/llvm/llvm-project/pull/106950
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
