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

[Ravitheja Addepally via lldb-dev]

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 ?

The use case is as follows ->
we are currently implementing support for Intel Processor Trace for lldb,
the way it is structured is that the lldb-server gathers trace data and we
have a tool running on top of SB API's
which does all the trace specific handling. So basically the client is sort
of transparent. We choose such a design so as to do the least amount of
changes in lldb.

On Thu, Jun 22, 2017 at 1:54 AM, Jim Ingham <jingham at apple.com> wrote:

> 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 <sas at cd80.net> 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 <jingham at apple.com> 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 at 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 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
> > > --
> > > --
> > > Stephane Sezer
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> > --
> > --
> > Stephane Sezer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170622/fe6b0f32/attachment.html>