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.
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).
Todd, do you know if distribution_id, os_build, os_kernel need to
converted to plain-text?
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]>> wrote:
On Jul 25, 2014, at 7:08 AM, Todd Fiala <[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]> | 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. Keep up to date with CSR on our
technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube,
www.youtube.com/user/CSRplc, Facebook,
www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at
www.aptx.com.
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
