I've been experimenting with returning richer error messages in debugserver recently, and I found a bug the other day where qLaunchSuccess returns its error code with an "E" followed by the text of the error message. If the error message contains one of the magic gdb RSP characters (#, $, *, }), lldb will often crash. We've seen packets like vAttach adopt a new method of returning an error message as Exx;HEX-ENCODED instead of the usual Exx.
We've had instances where packets need to be fixed in the past, e.g. Spencer Michaels reports a bug in the A packet here https://bugs.llvm.org/show_bug.cgi?id=42471 and I need to fix the constant values we use in the vFile packets. Spender and I were discussing a "qProtocolFixes" packet, but Fred suggested we could piggyback on qSupported. I liked that idea, so that's what I have implemented here.
lldb will send qLaunchSuccessASCIIHexErrorText in its qSupported request, and if this is a debugserver that has the fix, it will enable the corrected error reporting mode and include qLaunchSuccessASCIIHexErrorText in the qSupported response. I think this is a pretty clean way of fixing things like this, Greg/Pavel what do you think?
I also found a bug in debugserver's cstring_to_asciihex_string() function with high-bit set characters in the error string (e.g. a utf-8 character) with signed chars where we'd end up with a bunch of 0xff's in the ascii hex string.
I'm trying to make an API test for this but haven't found a good way to fake up enough of the lldb side to add a gdb_remote_client test yet.