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
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
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,
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
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?
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
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 ?
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
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
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
lldb-dev
> Sent: Wednesday, June 21, 2017 11:41 AM
> To: Ravitheja Addepally <ravithejaw...@gmail.com>
> Cc: LLDB <lldb-dev@lists.llvm.org>
> Subject: Re: [lldb-dev] Support for Error Strings in remote protocol
>
> +1 one from me. I like the idea a lot. Specific detai
+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
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
13 matches
Mail list logo