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

[Ravitheja Addepally via lldb-dev]

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@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Pavel Labath via lldb-dev]

+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
> 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 the decision here depends on how forward-compatible we want to
be. If we don't anticipate adding further fields here, then the format
can just be
EXX;message
and no quoting is needed. If we want to add more fields in the future
(I don't really see what could they be though), then we should stick
to the standard semi-colon delimited list  format. So, something like:
EXX;message:
But then we need to decide how to encode . I guess the most
"standard" approach would be to hex-encode it, although it will make
them hard to read manually.

>
> I guess removing EXX would make it incompatible with gdb-server. Also adding
> new packets to query errors might not be desired ?
I think we should keep the numeric codes. Sometimes it may be useful
to programmatically switch on them, and that's hard to do with a
string only. For compatibility's sake, I'd only send the error
messages if the client explicitly enables it via some packet.

pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Ted Woodward via lldb-dev]

What we can't do is require the remote server to support the new protocol. 
lldb-server isn't the only thing we talk to, and failing because we didn't get 
a specific non-RSP conformant error packet would be bad.

I like Pavel's idea of enabling it via a Q packet, and after being enabled it 
should always be optional.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel
> 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 June 2017 at 16:31, Ravitheja Addepally via lldb-dev  d...@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 the decision here depends on how forward-compatible we want to
> be. If we don't anticipate adding further fields here, then the format can 
> just
> be EXX;message and no quoting is needed. If we want to add more fields in
> the future (I don't really see what could they be though), then we should
> stick to the standard semi-colon delimited list  format. So, something like:
> EXX;message:
> But then we need to decide how to encode . I guess the most
> "standard" approach would be to hex-encode it, although it will make them
> hard to read manually.
> 
> >
> > I guess removing EXX would make it incompatible with gdb-server. Also
> > adding new packets to query errors might not be desired ?
> I think we should keep the numeric codes. Sometimes it may be useful to
> programmatically switch on them, and that's hard to do with a string only. For
> compatibility's sake, I'd only send the error messages if the client 
> explicitly
> enables it via some packet.
> 
> pl
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] IMPORTANT: LLVM.org server move on June 24th! (SVN impact)

[Tanya Lattner via lldb-dev]

LLVMers,
 
The LLVM.org  server which hosts SVN, GIT mirror, 
documentation, and the main LLVM.org  website is moving to a 
new server on June 24th.  As a result of the move commit access will be locked 
out beginning 09:00PDT on the 24th.  We hope to have the move complete and 
commit access restored to everyone in a timely manner, however, a move of this 
magnitude will take several hours to complete.
 
In addition, this is the first step in moving SVN to a new URL: svn.llvm.org 
 
You can continue to access SVN via the old URL llvm.org/svn but we would like 
people to start moving over to the new URL. This will allow us more flexibility 
in moving SVN and SSL certificates going forward.
 
After the server move, you will may need to do the following:
Switch to the new URL via this command (you may need to adjust for your 
specific repo):
svn switch —relocate https://llvm.org/svn/llvm-project/ 
https://svn.llvm.org/llvm-project/
Accept the new certificate when using svn
 
A huge thank you to Mike Edwards for leading and helping this move. Mike has 
generously donated his time to help with system administration going forward 
and is still looking for volunteers to help with our ongoing operations needs.  
If you are interested in helping out please contact Mike at m...@sqlby.me 
.
 
 
Thanks,
Tanya___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Stephane Sezer via lldb-dev]

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 extending the current integer list used for
errors?

On Wed, Jun 21, 2017 at 8:31 AM Ravitheja Addepally via lldb-dev <
lldb-dev@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@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-- 
-- 
Stephane Sezer
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Jim Ingham via lldb-dev]

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 could 
actually make these meaningful by keeping a common table.  But that would only 
work for lldbserver.

Jim


> On Jun 21, 2017, at 4:18 PM, 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 
> debugger is better suited to do the job.
> 
> Can this problem be solved by extending the current integer list used for 
> errors?
> 
> On Wed, Jun 21, 2017 at 8:31 AM 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 
> 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@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> -- 
> -- 
> Stephane Sezer
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Stephane Sezer via lldb-dev]

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 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 could
> actually make these meaningful by keeping a common table.  But that would
> only work for lldbserver.
>
> Jim
>
>
> > On Jun 21, 2017, at 4:18 PM, Stephane Sezer via lldb-dev <
> lldb-dev@lists.llvm.org> 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 debugger is better suited to do the job.
> >
> > Can this problem be solved by extending the current integer list used
> for errors?
> >
> > On Wed, Jun 21, 2017 at 8:31 AM Ravitheja Addepally via lldb-dev <
> lldb-dev@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@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > --
> > --
> > Stephane Sezer
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> --
-- 
Stephane Sezer
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Jim Ingham via lldb-dev]

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.  Maybe 
have a qUsesLLDBSERVERErrorNumbers packet as part of the handshake.

Jim


> On Jun 21, 2017, at 4:35 PM, Stephane Sezer  wrote:
> 
> 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 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 could 
> actually make these meaningful by keeping a common table.  But that would 
> only work for lldbserver.
> 
> Jim
> 
> 
> > On Jun 21, 2017, at 4:18 PM, 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 debugger is better suited to do the job.
> >
> > Can this problem be solved by extending the current integer list used for 
> > errors?
> >
> > On Wed, Jun 21, 2017 at 8:31 AM 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 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@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > --
> > --
> > Stephane Sezer
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> -- 
> -- 
> Stephane Sezer

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev