[Lldb-commits] [PATCH] Corrections for docs/lldb-gdb-remote.txt

[Todd Fiala]

Hey Matthew,

That 0 parameter to strtoul doesn't quite work like that.  The 0 indicates
that the input character string determines how the base is interpreted.  So
a 0x{hex} will get interpreted base 16, a standard non-zero-leading set of
decimal numbers is base 10, and a 0{octal} is octal.

See this snippet:
===
#include <cstdlib>
#include <iostream>

int main(int argc, char **argv)
{
    const unsigned long val1 = std::strtoul("0x10", nullptr, 0);
    const unsigned long val2 = std::strtoul("16", nullptr, 0);
    const unsigned long val3 = std::strtoul("020", nullptr, 0);

    std::cout << "val1: " << val1 << std::endl;
    std::cout << "val2: " << val2 << std::endl;
    std::cout << "val3: " << val3 << std::endl;

    if ((val1 == val2) && (val2 == val3) && (val1 == val3))
        std::cout << "equal!" << std::endl;
    else
        std::cout << "different!" << std::endl;
}
===

If you compile and run that with a command line something like this:

tfiala-macbookpro:cpp tfiala$ clang -std=c++11 -lc++ -o strtoul strtoul.cpp
tfiala-macbookpro:cpp tfiala$ ./strtoul
val1: 16
val2: 16
val3: 16
equal!
tfiala-macbookpro:cpp tfiala$

You'll see that 3 different strings with the same call to strtoul all get
interpreted as the same integer value - namely decimal 16.  The string
input is what determines the base.

So, it comes back to how is qHostInfo written in this case.  Going back to
RNBRemote.cpp, you'll see here in HandlePacket_qHostInfo():


        strm << "cputype:" << std::dec << cputype << ';';
        strm << "cpusubtype:" << std::dec << cpusubtype << ';';

they're getting written as decimal.

And in GDBRemoteCommunicationServer.cpp where lldb-platform sends the
content, it's also written as decimal (in Handle_qHostInfo()):

    if (cpu != LLDB_INVALID_CPUTYPE)
        response.Printf ("cputype:%u;", cpu);
    if (sub != LLDB_INVALID_CPUTYPE)
        response.Printf ("cpusubtype:%u;", sub);

Since they are written as decimal numbers, that's how the client code will
interpret it.  And so I believe the docs are correct in that regard for
qHostInfo.

-Todd


On Wed, Jun 11, 2014 at 10:10 PM, Matthew Gardiner <mg11 at csr.com> wrote:

> Todd Fiala wrote:
>
>> Hey Matthew,
>>
>> > 1. I've changed the base of cputype and cpusubtype to reflect the fact
>> that the code assumes base-16, and furthermore to be consistent with
>> qProcessInfo.
>>
>> I'm looking at the debugserver code (RNBRemote.cpp) and
>> lldb-platform/llgs code (GDBRemoteCommunicationServer.cpp) that produce
>> those values.  The cputype and cpusubtype all are being written decimal as
>> far as a I read it.  What context are you seeing hexadecimal?
>>
>> Thanks!
>>
>> -Todd
>>
>
> Hi Todd,
>
> I'm seeing the context as being assumed as hex in the parsing of the
> *inbound* qHostInfo in lldb.
>
> Check out: GDBRemoteCommunicationClient::GetHostInfo in
> GDBRemoteCommunicationClient.cpp
>
> see this code:
>
> if (name.compare("cputype") == 0)
> {
>    // exception type in big endian hex
>    cpu = Args::StringToUInt32 (value.c_str(), LLDB_INVALID_CPUTYPE, 0);
>   ...
> }
> else if (name.compare("cpusubtype") == 0)
> {
>  // exception count in big endian hex
>   sub = Args::StringToUInt32 (value.c_str(), 0, 0);
> ..
> }
>
> the third argument to StringToUInt32  is 0, which is passed to strtoul,
> which is interpreted as base-16. Thus the parsing side in lldb assumes
> these are base-16.
>
> A side issue is that the documentation to qProcessInfo in
> lldb-gdb-remote.txt which says base-16 for these same datas.
>
> So we have inconsistency in the docs between qProcessInfo and qHostInfo,
> and a bug between the sender and receiver of qHostInfo.
>
> thanks
> Matt
>
>
>
>
> 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.
>



-- 
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/20140611/626bd3c7/attachment.html>