<div dir="ltr">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 ?<div>Also the lldb-server already knows the target, would be useful if it could generate an error message as well ?</div><div><br></div><div>The use case is as follows -></div><div>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</div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 22, 2017 at 1:54 AM, Jim Ingham <span dir="ltr"><<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> On Jun 21, 2017, at 4:35 PM, Stephane Sezer <<a href="mailto:sas@cd80.net">sas@cd80.net</a>> wrote:<br>
><br>
> 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.<br>
><br>
> On Wed, Jun 21, 2017 at 4:33 PM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br>
> Because the gdb remote protocol docs explicitly state:<br>
><br>
> The error response returned for some packets includes a two character error number. That number is not well defined.<br>
><br>
> we don't put much stock in the actual error numbers.<br>
><br>
> 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.<br>
><br>
> Jim<br>
><br>
><br>
> > On Jun 21, 2017, at 4:18 PM, Stephane Sezer via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > 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.<br>
> ><br>
> > Can this problem be solved by extending the current integer list used for errors?<br>
> ><br>
> > On Wed, Jun 21, 2017 at 8:31 AM Ravitheja Addepally via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
> > Hello all,<br>
> >        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 ?<br>
> ><br>
> > A very simple proposal would be to just attach an error string maybe as a Name:Value Pair ? like so -><br>
> ><br>
> > EXX;"Error String"<br>
> >  or<br>
> > EXX;M"Error String"<br>
> ><br>
> > I guess removing EXX would make it incompatible with gdb-server. Also adding new packets to query errors might not be desired ?<br>
> ><br>
> ><br>
> > Regards,<br>
> > A Ravi Theja<br>
> ><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > lldb-dev mailing list<br>
> > <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br>
> > --<br>
> > --<br>
> > Stephane Sezer<br>
> > ______________________________<wbr>_________________<br>
> > lldb-dev mailing list<br>
> > <a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/lldb-dev</a><br>
><br>
> --<br>
> --<br>
> Stephane Sezer<br>
<br>
</div></div></blockquote></div><br></div>