This is an archive of the discontinued LLVM Phabricator instance.

Add gdb pretty printers for a wide variety of libc++ data structures (take 2).
ClosedPublic

Authored by saugustine on Sep 5 2019, 2:24 PM.

Details

Diff Detail

Repository
rL LLVM

Event Timeline

saugustine created this revision.Sep 5 2019, 2:24 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 5 2019, 2:24 PM
echristo accepted this revision.Sep 5 2019, 2:26 PM

LGTM still. Thanks :)

This revision is now accepted and ready to land.Sep 5 2019, 2:26 PM
This revision was automatically updated to reflect the committed changes.

Committed as r371131.

Apologies for being a bit late, just rotated on to buildbot monitoring duty.
The test is currently failing on all of our Arm and AArch64 builders:
With errors such as:

No symbol table is loaded.  Use the "file" command.
Traceback (most recent call last):
  File "/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-aarch64-linux/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'

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2293/steps/test.libcxx/logs/FAIL%3A%20libc%2B%2B%3A%3Agdb_pretty_printer_test.sh.cpp

There is a similar error on Arm 32-bit

No symbol table is loaded.  Use the "file" command.
Cannot parse expression `.L1185 4@r4'.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.

Traceback (most recent call last):
  File "/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv7-linux/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'

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux/builds/1024/steps/test.libcxx/logs/FAIL%3A%20libc%2B%2B%3A%3Agdb_pretty_printer_test.sh.cpp

I'm not sure what is going on here. It looks like the build is debug, or if it is something specific to our machines. Would you be able to investigate what could cause that error? If we can't work it out I recommend that we disable the test on Arm and AArch64.

MaskRay added a subscriber: MaskRay.EditedOct 2 2019, 3:54 AM

Apologies for being a bit late, just rotated on to buildbot monitoring duty.
The test is currently failing on all of our Arm and AArch64 builders:
With errors such as:

No symbol table is loaded.  Use the "file" command.
Traceback (most recent call last):
  File "/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-aarch64-linux/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'

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2293/steps/test.libcxx/logs/FAIL%3A%20libc%2B%2B%3A%3Agdb_pretty_printer_test.sh.cpp

There is a similar error on Arm 32-bit

No symbol table is loaded.  Use the "file" command.
Cannot parse expression `.L1185 4@r4'.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.

Traceback (most recent call last):
  File "/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv7-linux/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'

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux/builds/1024/steps/test.libcxx/logs/FAIL%3A%20libc%2B%2B%3A%3Agdb_pretty_printer_test.sh.cpp

I'm not sure what is going on here. It looks like the build is debug, or if it is something specific to our machines. Would you be able to investigate what could cause that error? If we can't work it out I recommend that we disable the test on Arm and AArch64.

I suspect this is a Python 2/3 difference.

check_literal = check_literal_string.encode("utf-8")

The result of 'a'.encode('utf-8') is str in Python 2, while bytes in Python 3. The code may be written for Python 2.

I'm not sure what is going on here. It looks like the build is debug, or if it is something specific to our machines. Would you be able to investigate what could cause that error? If we can't work it out I recommend that we disable the test on Arm and AArch64.

I suspect this is a Python 2/3 difference.

check_literal = check_literal_string.encode("utf-8")

The result of 'a'.encode('utf-8') is str in Python 2, while bytes in Python 3. The code may be written for Python 2.

Thanks, that would make sense. It seems like the Python interpreter used is the version that gdb is built for:
On the system python --version is 2.7.12
On GDB I get:

(gdb) py
>import sys
>print (sys.version)
>end
3.5.2 (default, Nov 23 2017, 16:37:01) 
[GCC 5.4.0 20160609]

ldd on gdb gives me:

libpython3.5m.so.1.0 => /usr/lib/aarch64-linux-gnu/libpython3.5m.so.1.0 (0x0000ffff8b6dc000)

If that is the case and we can't know which version of python gdb is going to be built with (this is Ubuntu 16.04 on Arm and AArch64) then the scripts ought to be Python version neutral?

I'm not sure what is going on here. It looks like the build is debug, or if it is something specific to our machines. Would you be able to investigate what could cause that error? If we can't work it out I recommend that we disable the test on Arm and AArch64.

I suspect this is a Python 2/3 difference.

check_literal = check_literal_string.encode("utf-8")

The result of 'a'.encode('utf-8') is str in Python 2, while bytes in Python 3. The code may be written for Python 2.

Thanks, that would make sense. It seems like the Python interpreter used is the version that gdb is built for:
On the system python --version is 2.7.12
On GDB I get:

(gdb) py
>import sys
>print (sys.version)
>end
3.5.2 (default, Nov 23 2017, 16:37:01) 
[GCC 5.4.0 20160609]

ldd on gdb gives me:

libpython3.5m.so.1.0 => /usr/lib/aarch64-linux-gnu/libpython3.5m.so.1.0 (0x0000ffff8b6dc000)

If that is the case and we can't know which version of python gdb is going to be built with (this is Ubuntu 16.04 on Arm and AArch64) then the scripts ought to be Python version neutral?

Pushed a hypothetical fix rL373452...

(I haven't set up the libc++ + gdb testing environment yet.)

Pushed a hypothetical fix rL373452...

(I haven't set up the libc++ + gdb testing environment yet.)

Thanks, the libc++ buildbots tend to run infrequently, due to being on the same machine as a slow running full build and test bot. With luck it will be green tomorrow. http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux is one to watch.