diff options
| author | Felipe de Azevedo Piovezan <fpiovezan@apple.com> | 2025-10-15 07:34:06 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-10-15 07:34:06 -0700 |
| commit | ccf6e0250b5757197788f0fadb896a8912419329 (patch) | |
| tree | db6a5057df4b7d5a0761afa41d2d1f127f560706 /clang/lib/Frontend/CompilerInvocation.cpp | |
| parent | aa435772780ec17fda440f58d00d3d8703d7bfda (diff) | |
| download | llvm-ccf6e0250b5757197788f0fadb896a8912419329.zip llvm-ccf6e0250b5757197788f0fadb896a8912419329.tar.gz llvm-ccf6e0250b5757197788f0fadb896a8912419329.tar.bz2 | |
[lldb] Parse qSupported MultiMemRead tag in GDB Remote Client (#163249)
This is in preparation for the new MultiMemRead packet discussed in the
RFC [1].
An alternative to using `qSupported` would be having clients send an
empty `MultiMemRead` packet. However, this is problematic because the
already-existing packet `M` is a prefix of `MultiMemRead`; an empty
reply would be ambiguous in this case. It is also risky that the stub
might interpret the `MultiMemRead` as a valid `M` packet.
Another advantage of `qSupported` is that this packet is already
exchanged, so parsing a new field is simpler than having to exchange one
extra packet.
[1]:
https://discourse.llvm.org/t/rfc-a-new-vectorized-memory-read-packet/88441
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions