[libcxx-dev] gdb on libcxx-libcxxabi-libunwind-armv7-linux build bot
Adhemerval Zanella via libcxx-dev
libcxx-dev at lists.llvm.org
Mon Sep 9 12:24:47 PDT 2019
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.
>
More information about the libcxx-dev
mailing list