[Lldb-commits] [PATCH] Improvement for lldb-gdb-remote.txt qHostInfo documentation
Todd Fiala
tfiala at google.com
Tue Jul 29 07:54:35 PDT 2014
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 <mg11 at csr.com> 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 <mg11 at csr.com <mailto:
>> mg11 at csr.com>> 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
>> <jason at molenda.com <mailto:jason at molenda.com>
>> <mailto:jason at molenda.com <mailto:jason at molenda.com>>> wrote:
>>
>>
>> On Jul 25, 2014, at 7:08 AM, Todd Fiala <tfiala at google.com
>> <mailto:tfiala at google.com>
>> <mailto:tfiala at google.com <mailto:tfiala at google.com>>> 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 | tfiala at google.com
>> <mailto:tfiala at google.com> <mailto:tfiala at google.com
>> <mailto:tfiala at google.com>> | 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 | tfiala at google.com <mailto:
>> tfiala at google.com> | 650-943-3180
>>
>>
>>
>
--
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140729/e57b84fc/attachment.html>
More information about the lldb-commits
mailing list