Cool - sounds all good to me since we don't have a backwards compatibility problem. Now would be the time to do it :-)
-Todd On Fri, Jul 25, 2014 at 12:40 PM, Jason Molenda <[email protected]> wrote: > > On Jul 25, 2014, at 7:08 AM, Todd Fiala <[email protected]> wrote: > > > Hey Jason, > > > > I don’t know about llgs or how much work it would be to change the > kalimba gdbserver stub. > > > > Currently GDBRemoteCommunicationServer, used by both llgs and > lldb-platform, does send the triple as hex encoded via this code: > > > > response.PutCString("triple:"); > > response.PutCStringAsRawHex8(host_triple.getTriple().c_str()); > > > > We can easily not do that as you suggest. Are there any ramifications > for your usage of lldb-platform, though? We’d need to change the receiver > code of that, which would then differ based on which lldb-platform version > you’re talking to. > > It sounds like Matthew is open to changing the kalimba stub. We should > get rid of the hex-ascii strings (along with distribution_id, os_build, > os_kernel) everywhere. lldb-platform is not bundled/distributed in any > products so we don't have to worry about deployed versions. > > hostname is less clear-cut because there we're dealing with a > user-specified string and that may include one of # $ } *. > > Personally, I wish the whole of gdb-remote protocol required the use of > the binary packet escape protocol which says that any of these 4 > metacharacters that is meant to be sent in the body of a packet is prefixed > with } and is xor'ed with 0x20. But that's not what the protocol says so > we need to do these things.. -- Todd Fiala | Software Engineer | [email protected] | 650-943-3180
_______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
