Hello,
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
required.
On 26 June 2017 at 18:19, Chris Quenelle via lldb-dev
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 numb
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, si
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 abou
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
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? I
On 22 June 2017 at 00:18, Stephane Sezer via lldb-dev
wrote:
> What's the specific use case that you're trying to support with error
> messages in the protocol? My initial thought on this is that it's not really
> the debug server's job to generate human-readable error messages and that
> the debu
That's the other option of decoding error codes at the client, there is the
obvious downside of the common error table to become very big ? considering
the number of OS's and Targets ?
Also the lldb-server already knows the target, would be useful if it could
generate an error message as well ?
Th
Right. I wasn't actually arguing one method over the other. Mostly pointing
out that you can't take error numbers seriously in general, and that
consequently if we go the error number route, you have to know you are talking
to lldb-server and particularly one that has rational error numbers.
True, but the error strings would be only available with lldb-server as
well. Keeping a common table of error numbers seems like a good solution.
On Wed, Jun 21, 2017 at 4:33 PM Jim Ingham wrote:
> Because the gdb remote protocol docs explicitly state:
>
> The error response returned for some pa
Because the gdb remote protocol docs explicitly state:
The error response returned for some packets includes a two character error
number. That number is not well defined.
we don't put much stock in the actual error numbers.
If you can determine that you are talking to lldb-server, then we co
What's the specific use case that you're trying to support with error
messages in the protocol? My initial thought on this is that it's not
really the debug server's job to generate human-readable error messages and
that the debugger is better suited to do the job.
Can this problem be solved by ex
avel
> Labath via lldb-dev
> Sent: Wednesday, June 21, 2017 11:41 AM
> To: Ravitheja Addepally
> Cc: LLDB
> Subject: Re: [lldb-dev] Support for Error Strings in remote protocol
>
> +1 one from me. I like the idea a lot. Specific details below.
>
> On 21 Ju
+1 one from me. I like the idea a lot. Specific details below.
On 21 June 2017 at 16:31, Ravitheja Addepally via lldb-dev
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
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 t
15 matches
Mail list logo
