labath wrote: > The problem is here > lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp, line > 3235 inside GDBRemoteCommunicationClient::GetFilePermissions() > > ``` > file_permissions = mode & (S_IRWXU | S_IRWXG | S_IRWXO); > ```
Okay, so I think this is the bug. The protocol code should not be depending on the host definitions of the permission constants. Would you be interested in creating a patch to change this so that it uses lldb's `eFilePermissions***` enums (which are the same everywhere(*)). I don't think it is necessarily up to you to fix this issue, but you do seem to care about the windows->linux configs, and this is approximately the only configuration in which this bug manifests itself. And it's definitely not a big bug, but it could cause some surprises when debugging in these setups. In case you do not want to make that change, I'd say that the appropriate decorator is `@expectedFailureAll(hostoslist=["windows"])` with a reference to this issue, as this is something that is supposed to work, but fails due to an lldb bug. (*) Technically, there is no requirement that the [gdb-protocol values](https://github.com/llvm/llvm-project/blob/b6f050fa129b08b6bc35168f0b8010742cd1ed9d/lldb/docs/resources/lldbgdbremote.md?plain=1#L2302) match `lldb` public enums. Puristically, one ought to define separate constants for the protocol and then convert them between the two. However, the two definitions happen to match in this case, and both of them are part of stable APIs so they can't go out of sync and I think we can skip the conversion step. https://github.com/llvm/llvm-project/pull/92088 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
