Okay, sounds good Matthew. I'll have a look at the review you put out sometime today.
On Tue, Jul 29, 2014 at 2:22 AM, Matthew Gardiner <[email protected]> wrote: > Guys, > > I'm going to limit the scope of my current work to just fixing the triple > (i.e. change it to plaintext string encoding, and the revert > documentation). I'm unclear of the intended encoding of the other items > we'd mentioned. I'll come back to them later. > > Matt > > Todd Fiala wrote: > >> >> >> >> On Mon, Jul 28, 2014 at 2:25 AM, Matthew Gardiner <[email protected] <mailto: >> [email protected]>> wrote: >> >> Todd/Jason, >> >> I'm happy to do this work, i.e. changes to >> GDBRemoteCommunicationServer.cpp and >> GDBRemoteCommunicationClient.cpp. (And to change the kalimba stub >> is easy). As I have just acquired commit access to lldb this could >> be a useful piece of work to introduce me to the Phabricator >> review process. >> >> >> Great, have at it! >> >> A couple of questions remain, though. >> >> Todd's comment: >> >> >> "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." >> >> >> Is that meaning that there are installed lldb-platform binaries >> which will now be broken against a version of lldb which expects >> plain text triples? Is that a problem? (that is, __will__ people >> upgrade both lldb and lldb-platform separately). >> >> >> Matthew, this was my misunderstanding. I had thought lldb-platform >> shipped with all the Apple platforms. They fixed my understanding - it >> only gets downloaded to devices as needed but doesn't live there. So this >> is a non-issue. As for llgs using it, that should not be an issue as llgs >> is just getting functional now and backwards support isn't a concern just >> yet. >> >> Todd, do you know if distribution_id, os_build, os_kernel need to >> converted to plain-text? >> >> >> I added distribution_id to indicate the Linux distribution, since it >> looks like on Android that might be the only way I can tell Android and its >> Androidisms apart from a stock Linux. On Linux, it grabs the content from >> the lsb_release exe, which really could be anything. If we wanted to >> switch that to binary encoding, that should be fine. You could change that >> one. >> >> Somebody else should probably comment on os_build/os_kernel. >> >> Jason, what is the problem with hostname? Previously you wrote >> that we are dealing with a user-specified string that may include >> non-alphanumeric characters. So in lldb/GDB-RSP context is a >> hostname different than that defined in >> http://tools.ietf.org/html/rfc952? >> >> Matt >> >> Todd Fiala wrote: >> >> 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] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> >> On Jul 25, 2014, at 7:08 AM, Todd Fiala <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[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] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> | 650-943-3180 <tel:650-943-3180> >> >> >> >> >> >> To report this email as spam click here >> <https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==>. >> >> >> >> >> Member of the CSR plc group of companies. CSR plc registered in >> England and Wales, registered number 4187346, registered office >> Churchill House, Cambridge Business Park, Cowley Road, Cambridge, >> CB4 0WZ, United Kingdom >> More information can be found at www.csr.com <http://www.csr.com>. >> >> Keep up to date with CSR on our technical blog, www.csr.com/blog >> <http://www.csr.com/blog>, CSR people blog, www.csr.com/people >> <http://www.csr.com/people>, YouTube, www.youtube.com/user/CSRplc >> <http://www.youtube.com/user/CSRplc>, Facebook, >> www.facebook.com/pages/CSR/191038434253534 >> <http://www.facebook.com/pages/CSR/191038434253534>, or follow us >> on Twitter at www.twitter.com/CSR_plc >> <http://www.twitter.com/CSR_plc>. >> >> New for 2014, you can now access the wide range of products >> powered by aptX at www.aptx.com <http://www.aptx.com>. >> >> >> >> >> >> -- >> Todd Fiala | Software Engineer | [email protected] <mailto: >> [email protected]> | 650-943-3180 >> >> >> > -- Todd Fiala | Software Engineer | [email protected] | 650-943-3180
_______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
