Daniel Prilik

#100 merged in the first bit of explicit LLVM compat to `gdbstub`. Admittedly, these changes were merged in a pretty "laissez faire" manner, as they were fairly minor (allowing a...

Ah, interesting! Reading through the LLDB GDB RSP spec doc, it looks like LLDB adds a `qGDBServerVersion` packet, which allows servers to report what "version" of the LLDB protocol is...

Some relevant discussion regarding this issue: https://github.com/daniel5151/gdbstub/pull/72#discussion_r711225603

This is a great summary of our discussion - thanks you! Personally, I prefer the first way. It gives the end user the ultimate flexibility wrt. where they'd like to...

I'm not entirely sure what you're suggesting with that `bytes` example, but as you've pointed out, `bytes` requires `alloc`, which is a non-starter for core `gdbstub` code. Any solution will...

Ahh, yes, sure, that's certainly a valid way of doing it (i.e: instead of storing a slice reference directly, store the offsets into `buf` corresponding to the field data). FWIW,...

So, to reiterate - it is entirely possible to rewrite the current `m` packet implementation (and many others) to use 100% of the packet buffer, using the "store a `start..end`...

Again - and I really cannot stress this enough: using `bytes` or any similar `alloc`-dependent crates is not an option. Period. `gdbstub` is a `no_std` + `no_alloc` library. Every single...

Ah, apologies - I didn't catch the part about wanting to upstream these changes... I don't believe that `bytes` would want to upstream that kind of change, as it doesn't...

I would also leave the following links as well: - https://github.com/bminor/binutils-gdb/blob/master/gdb/features/rs6000/powerpc-32.xml - https://github.com/bminor/binutils-gdb/blob/master/gdb/features/rs6000/power-core.xml - https://github.com/bminor/binutils-gdb/blob/master/gdb/features/rs6000/power-fpu.xml Just as a reminder though, this issue is not a bug or a blocker -...