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

[Chris Quenelle via lldb-dev]

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 of
new code.

If many things can go wrong in the server, then you might want to have some
arbitrary
lines of text that can be retrieved by the client, and which are defined as
"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 human
on request.

That would give a lot of flexibility for the server to spit ad-hoc strings
into the error buffer.

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.



On Mon, Jun 26, 2017 at 7:29 AM, Ravitheja Addepally <
ravithejawork at gmail.com> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170626/6c6fb8e3/attachment.html>