[lldb-dev] Support for Error Strings in remote protocol
Ravitheja Addepally via lldb-dev
lldb-dev at lists.llvm.org
Tue Jun 27 08:18:54 PDT 2017
I would just like to add one more point to this discussion about
error strings being human readable or not, I guess the whole purpose
of having error strings, is to present them to human users right ? i mean a
use case of sending strings, that are not human readable won't be
So I can work on this point and upload a patch for review. I will add all
people in this discussion in the review as well.
On Tue, Jun 27, 2017 at 11:27 AM, Pavel Labath <labath at google.com> wrote:
> On 26 June 2017 at 18:19, Chris Quenelle via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
> > My main concern was that *if* strings are added, there's some
> > clear documentation about the relationship between the string
> > and the number to explain what's going on. Based on other
> > emails in this thread it seems like the numbers are so unreliable that
> > it might not be worth the trouble.
> > What about this approach instead?
> > Define a new mode of operation called something like "extended error
> > response"
> > and invent some way for the client to 1) detect if it's supported in the
> > server and then
> > 2) to enable the mode in the server.
> > Then define a better error interface. You'd want it to resemble the
> > existing one
> > to make it easy for clients to enable it without having to write a bunch
> > new code.
> > If many things can go wrong in the server, then you might want to have
> > arbitrary
> > lines of text that can be retrieved by the client, and which are defined
> > "human readable only" In other words, warn clients not to parse this
> > extended
> > "Error log" type of string stuff. The client could dump that to the
> > on request.
> > That would give a lot of flexibility for the server to spit ad-hoc
> > into the error buffer.
> I think that pretty much sums up what we were talking about. The
> client would enable the packet via e.g. QEnableStringErrors packet
> (the servers already know to reply "unsupported packet" to any packets
> they don't understand). Then the server can send
> "Exx;some_error_string" (instead of the usual "Exx"). Later, when the
> client converts that into a Status object he will use that string to
> initialize the error string. If the error string is not present he
> will simply initialize the error string to "Error 47". All of this
> would be completely invisible to all but the lowest layers of the gdb
> protocol code.
> > You could also define a strict set of numeric codes for things that are
> > supposed to
> > common and stable between server versions and implementations. But that
> > would
> > still be within the "extended error response" mode.
> Right I don't think we have a use case for these extended error codes,
> so I'd postpone that discussion until a need arises. (Mainly because
> maintaining a set of backward/forward compatible set of numeric error
> codes is a pain).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev