[Lldb-commits] [PATCH] D79614: Fix error reporting for qLaunchSuccess, check for fix/enable it via qSupported

Jason Molenda via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Sat May 9 21:48:17 PDT 2020


jasonmolenda added a comment.

In D79614#2028295 <https://reviews.llvm.org/D79614#2028295>, @clayborg wrote:

> In D79614#2027869 <https://reviews.llvm.org/D79614#2027869>, @jasonmolenda wrote:
>
> > In D79614#2027861 <https://reviews.llvm.org/D79614#2027861>, @clayborg wrote:
> >
> > > Why not just fix qLaunchSuccess by passing the string through a "escape_string(...)" function? Any packet that can return a string with unknown content should be escaped correctly. Adding a new packet doesn't really fix the problem in older debugserver/lldb-server binaries anyway.
> >
> >
> > lldb wouldn't know whether to decode the returned error string or not -- short of using a debugserver version #.  We'll need to interoperate with debugservers that send the unescaped qLaunchSuccess error messages for years to come.
>
>
> It should always decode a raw string so I don't see what you mean here. Any packet that returns a normal string, not hex ascii encoded, must escape the string. The only bug here is that we are not escaping the string that debugserver sends back. No need for the hex ASCII stuff if we escape any special characters right?


Ah, I see what you're getting at --- yes I bet if we switch to using the binary escape protocol for the error message that would work just as well.  It's a one-off way to report an error message which doesn't thrill me, but you're right that this may not be worth the addition to qSupported etc.  I'll confirm that using the standard escaping is sufficient and decide whether to just do that, it's probably the right call.  Thanks for the feedback.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79614/new/

https://reviews.llvm.org/D79614





More information about the lldb-commits mailing list