[libcxx-dev] gdb on libcxx-libcxxabi-libunwind-armv7-linux build bot

Tue Sep 10 14:45:01 PDT 2019

I'll look into sorting this out. Strange that no other build bots are using
python3 by default.

On Tue, Sep 10, 2019 at 12:38 PM Adhemerval Zanella <
adhemerval.zanella at linaro.org> wrote:

> Hi Sterling,
>
> It in indeed a python3 issue, where it is being used as default on the
> bot. Besides the check_literal format issue, python3 next iteration
> method has changed its name to __next__ which requires some internal
> adjustments. I am not trying to fix a remaining issue with bitset
> printer.
>
> On 09/09/2019 16:24, Adhemerval Zanella wrote:
> > At least on my testing it seems the __r_ field does exist:
> >
> > $ gdb ./gdb_pretty_printer_test.sh.cpp.tmp.exe
> > [...]
> > (gdb) b string_test
> > (gdb) r
> > [1]+  Stopped                 gdb
> ./gdb_pretty_printer_test.sh.cpp.tmp.exe
> > $ fg
> > [...]
> > Breakpoint 1, string_test () at
> /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp:135
> > 135       std::string short_string("kdjflskdjf");
> > (gdb) n
> > (gdb) p short_string
> > $1 = {<std::__1::__basic_string_common<true>> = {<No data fields>},
> static __short_mask = 1, static __long_mask = 1,
> >   __r_ = {<std::__1::__compressed_pair_elem<std::__1::basic_string<char,
> std::__1::char_traits<char>, std::__1::allocator<char> >::__rep, 0, false>>
> = {__value_ = {{__l = {__cap_ = 1784965908,
> >             __size_ = 1802726502, __data_ = 0x666a64 <error: Cannot
> access memory at address 0x666a64>}, __s = {{__size_ = 20 '\024', __lx = 20
> '\024'}, __data_ = "kdjflskdjf"}, __r = {__words = {
> >               1784965908, 1802726502,
> >               6711908}}}}},
> <std::__1::__compressed_pair_elem<std::__1::allocator<char>, 1, true>> =
> {<std::__1::allocator<char>> = {<No data fields>}, <No data fields>}, <No
> data fields>},
> >   static npos = 4294967295}
> >
> > The only unexpected thing is for some reason gdb is being stopped just
> after
> > the program start (not sure how it influences the testcase or if it is
> something
> > expected).
> >
> > Also adding a 'print("VALUE_FIELD: ", value_field)' just after the
> value_field
> > attribution I am seeing:
> >
> > $ /usr/bin/gdb -nx -batch -iex "set autoload off" -ex "source
> /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/utils/gdb/libcxx/printers.py"
> -ex "python register_libcxx_printer_loader()" -ex "source
> /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.py"
> gdb_pretty_printer_test.sh.cpp.tmp.exe 2>&1 | tee _out
>
>                         No symbol table is loaded.  Use the "file"
> command.
>
>             Breakpoint 1 at 0x1179c: file
> /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp,
> line 57.               Loading libc++ pretty-printers.
>
>
>   Cannot parse expression `.L1185 4 at r4'.
>
>                                                            warning:
> Probes-based dynamic linker interface failed.
>
>                                                Reverting to original
> interface.
> >
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library
> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> > FAIL:
> /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp:137
> > GDB printed:
> >    VALUE_FIELD:  {{__l = {__cap_ = 1784965908, __size_ = 1802726502,
> __data_ = 0x666a64 <error: Cannot access memory at address 0x666a64>}, __s
> = {{__size_ = 20 '\024', __lx = 20 '\024'}, __data_ = "kdjflskdjf"}, __r =
> {__words = {1784965908, 1802726502, 6711908}}}}
> > "kdjflskdjf"
> > Value should match:
> > Traceback (most recent call last):
> >   File
> "/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.py",
> line 64, in invoke
> >     print("   " + check_literal)
> > TypeError: Can't convert 'bytes' object to str implicitly
> > terminate called after throwing an instance of
> 'gdb_exception_RETURN_MASK_ERROR'
> >
> >
> > On 09/09/2019 15:29, Sterling Augustine wrote:
> >> I think the encoding failure (which would be python 2 vs 3) is a
> secondary failure--already deep inside the error handling. The real problem
> is the
> >>
> >> File
> "/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/utils/gdb/libcxx/printers.py",
> line 221, in to_string
> >>     value_field = _value_of_pair_first(self.val["__r_"])
> >> gdb.error: There is no member named __r_.
> >>
> >> Which means that maybe the test case is getting compiled or linked
> differently. At least in such a way that the field "__r_" doesn't exist (at
> least not in debug info). But I would be quite puzzled as to why this bot
> has a different libcxx build or debug info than all the others.
> >>
> >> On Mon, Sep 9, 2019 at 11:15 AM Adhemerval Zanella <
> adhemerval.zanella at linaro.org <mailto:adhemerval.zanella at linaro.org>>
> wrote:
> >>
> >>     Hi Sterling,
> >>
> >>     Maxim has asked to take a loot at it.  The failure is essentially:
> >>
> >>     FAIL:
> /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp:137
> >>     GDB printed:
> >>        <incomplete type>
> >>     Value should match:
> >>     Traceback (most recent call last):
> >>       File
> "/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.py",
> line 64, in invoke
> >>         print("   " + check_literal)
> >>     TypeError: Can't convert 'bytes' object to str implicitly
> >>
> >>     I am not sure if it is something related to python2/3. The system
> does have
> >>     both installed (python 2.7.12 and 3.5.2, with 2 being the
> default).  I tried
> >>     to issue the faulty testcase with python3, and it shows the same
> issue
> >>
> >>     I am not very familiar with this code, but trying to make peace with
> >>     the types by changing it to:
> >>
> >>      52             else:
> >>      53                 check_literal =
> expectation_val.string(encoding="utf-8")
> >>      54                 check_literal_utf8 =
> check_literal.encode("utf-8")
> >>      55                 test_fails = value.encode("utf-8") !=
> check_literal_utf8
> >>
> >>     Also does not help either.  For the change above, the first failure
> shows:
> >>
> >>     FAIL:
> /home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/test/pretty_printers/gdb_pretty_printer_test.sh.cpp:137
> >>     GDB printed:
> >>        Traceback (most recent call last):
> >>       File
> "/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv8-linux-noexceptions/llvm/projects/libcxx/utils/gdb/libcxx/printers.py",
> line 221, in to_string
> >>         value_field = _value_of_pair_first(self.val["__r_"])
> >>     gdb.error: There is no member named __r_.
> >>
> >>     Value should match:
> >>        "kdjflskdjf"
> >>
> >>     Which indicates that something is still missing here. I am checking
> if it
> >>     is possible to give you direct access to the bot.
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190910/5bb61c18/attachment-0001.html>