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 <jing...@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 <s...@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 <jing...@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@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
