[lldb-dev] Support for Error Strings in remote protocol

[Jim Ingham via lldb-dev]

The gdb remote protocol documents say the error numbers are not well defined.  They are not meant to have any meaning.

The lldb Status (née Error) objects have different namespaces, some of which (like the Posix errors) have significant numbering, so the numbers in those cases are preserved, since they might be significant to somebody.  

But we never saw any advantage to adding significant numbers to the error strings for lldb's internal errors, so we didn't do that.  The primary things in the Status class are that you had an error and the string.  This has not caused any problems internal to lldb.  We don't have a lot of operations that can fail in multiple ways that can't be independently screened and which you would react to differently depending on the mode of failure.  So this would have been an unnecessary complexity.

As to error strings from lldbserver, it seems useful to send them, but mostly because the server might be able to add bits of detail that are unavailable to lldb.  To that end, having the server present the errors is more likely to generate helpful information for the user than having a set of numbers lldb decodes statically.  Again, I doubt that making the numbers significant will be particularly useful, but carrying some extra info about the failure that might be significant to the user of lldb does seem worth a little effort.

Jim


> On Jun 26, 2017, at 7:29 AM, Ravitheja Addepally via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Hello,
>   From my understanding (please correct me if i am wrong) , currently the error codes returned by lldb-server are completely arbitrary.
> Now the SBError class in the public API interface of lldb does contain a string. I think in erroneous cases, lldb seems to set the String
> in the lldb Status class more often than the error code. I seriously doubt if there is a coherent structure in the error classes.
> 
> This whole error structure is borrowed from GDB, which is vague about error codes. Now there are two questions we need to answer ->
> 1) Do we want to have ability to send error strings in the error packets ?
> 2) If Yes then how ?
> 
> 
> 
> On Fri, Jun 23, 2017 at 1:01 AM, Chris Quenelle <cq7840 at gmail.com> wrote:
> I’m just a new lurker here, so maybe this is obvious…
> 
> Is the string part of the programmatic interface?  Or just a comment?
> Does the same numeric code always have the same string?
> If the same numeric code can have different strings, then the string
> represents a specialization of the error code?  If clients depend on
> the data that’s in the string, then they may not work correctly in
> modes of operation where the string is not available from the server.
> 
> If it’s intended to be part of the API then maybe a structured name/value
> approach might be better?
> 
> Or maybe it’s just supposed to be a form self-documentation so that inspection
> of the raw error codes is easier to diagnose?  In that case maybe the string
> is always 1-to-1 with the error code?
> 
> > On Jun 21, 2017, at 8:31 AM, Ravitheja Addepally via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> >
> > Hello all,
> >        Currently the remote protocol in LLDB does not allow sending Error Strings in response to remote packets, it only allows for "ENN" format where N is a hex integer. In our current ongoing work, we would like to have support for Sending Error Strings from lldb-server. I would like to invite any opinions or suggestions in this matter ?
> >
> > A very simple proposal would be to just attach an error string maybe as a Name:Value Pair ? like so ->
> >
> > EXX;"Error String"
> >  or
> > EXX;M"Error String"
> >
> > I guess removing EXX would make it incompatible with gdb-server. Also adding new packets to query errors might not be desired ?
> >
> >
> > Regards,
> > A Ravi Theja
> >
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev