do not fail on unknown HostIoOpenFlags

[mrk-its]

Description

gdbstub fails when unknown file open flags are passed with:

gdbstub encountered a fatal error: Could not parse the packet into a valid command: MalformedCommand

This bug appeared with lldb sending platform put-file command, appending following File:open arguments:
612e6f7574,40000601,000001ed

The simple solution is to use from_bits_truncate to ignore unknown flags.

API Stability

• This PR does not require a breaking API change

Checklist

• Implementation

  • cargo build compiles without errors or warnings
  • cargo clippy runs without errors or warnings
  • cargo fmt was run
  • All tests pass

• Documentation

  • Updated CHANGELOG.md

[daniel5151]

While this PR does solve your immediate issue, it is not a proper solution to the problem.
Namely, it seems that the LLDB RSP deviates from GDB RSP wrt how it handles vFile packets.

See: https://github.com/llvm/llvm-project/blob/ec642ceebc1aacc8b16249df7734b8cf90ae2963/lldb/docs/lldb-platform-packets.txt#L6-L11

I'll try to find some time soon to think of the best way to work around this issue, but unfortunately, I cannot merge this PR in its current state.

Note that as it stands, gdbstub doesn't explicitly support lldb, so this isn't strictly a "bug" as it is a new feature request (i.e: supporting LLDB).

[daniel5151]

That said, I sincerely appreciate the PR, and for bringing this issue to my attention.

[mrk-its]

np, so I'll stay with my fork

[daniel5151]

I did a bit more digging and found this:

https://github.com/llvm/llvm-project/blob/ec642ceebc1aacc8b16249df7734b8cf90ae2963/lldb/include/lldb/Host/File.h#L47-L66

Look like LLDB's flags are a strict superset of GDB flags, which means it should be possible to support these additional flags without breaking existing GDB implementation / requiring any breaking API changes.

If you'd like to send a PR that adds these additional variants, I'd be happy to merge that one.

[daniel5151]

oh, wait, maybe not actually...

looks like this was only a recent change, and older versions of lldb will use different enum values: llvm/llvm-project@8bbef4f

I suspect we'd want to support older clients as well, which means this continues to be a tricky problem to solve nicely...

[mrk-its]

oh, wait, maybe not actually...

looks like this was only a recent change, and older versions of lldb will use different enum values: llvm/llvm-project@8bbef4f

I suspect we'd want to support older clients as well, which means this continues to be a tricky problem to solve nicely...

Currently gdbstub fails for both old and new versions, so adding support for new ones only would be a big improvement :)

[daniel5151]

Yeah, you know what - fair enough! We can punt the hard problem of supporting older LLDB clients down the line, and get you unblocked for now in a non-breaking way.

So sure, feel free to send a PR my way with these new variants :)

[daniel5151]

FYI, I've opened a tracking issue for the broader LLDB compatibility story over at #99