LLDB type summaries not displayed for libcxx types

Subprojects LLDB
1

Hi there - I’m currently working on Google’s flutter project and I am having some trouble with visualization of STL types. The project uses libcxx from a git submodule rather than the system installed library.

Reproduced on Arch Linux x86_64, LLDB 20.1.8

Steps to reproduce

  1. Setup Google’s tooling:

    $ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
$ export PATH=$(pwd)/depot_tools:${PATH}

  2. Clone the flutter repository

    $ git clone https://github.com/flutter/flutter.git
$ cd flutter
$ gclient sync

  3. Build the flutter engine

    $ export PATH=$(pwd)/engine/src/flutter/bin:${PATH}
$ et build --config=host_debug_unopt

  4. Run a unit test from LLDB

    $ cd engine/src/out/host_debug_unopt/exe.unstripped
$ lldb impeller_unittests 
$ breakpoint set --file blit_pass_gles.cc --line 84
$ run --gtest_filter=Play/DisplayListTest.CanDrawImage/OpenGLES
$ frame variable this->commands_

Expected result

BlitPlassGLES::_commands is an std::vector and I would expect it to be recognized by LLDB’s built in support for libcxx types

Actual result

The variable is printed in raw format:

(std::vector<std::unique_ptr<impeller::BlitEncodeGLES> >) this->commands_ = {
  __begin_ = 0x000055555a8451f0
  __end_ = 0x000055555a8451f8
  __cap_ = 0x000055555a8451f8
  __padding1_548_ = {}
  __alloc_ = {}
  __padding2_548_ = {}
2

Does LLDB choke on other kinds of vectors? A simple one like std::vector<int> would be good to check. Also if you run:

log enable lldb formatters -f /tmp/lldb.log

And then reproduce the issue. Are there any failure messages in the logfile?

The project uses libcxx from a git submodule rather than the system installed library.

Could the libc++ version be newer than the one shipped with the LLVM installation on your system? If so, there might have been layout changes in the new libc++ that you’re using that the old LLDB on your system doesn’t know about yet. That would be my best guess

1 Like
3

Thanks for the logging hint - it looks like it’s because the project has a custom _LIBCPP_ABI_NAMESPACE defined. I’ll do some more testing and submit a feature request for support for custom namespaces if that’s the case.

#define _LIBCPP_ABI_NAMESPACE _fl
4

Heh LLDB expects the libc++ namespaces to start with a __ prefix: llvm-project/lldb/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp at 5099c07fa0773a24337e9d218bbc408eacb791a0 · llvm/llvm-project · GitHub

I guess the thought process was _LIBCPP_ABI_NAMESPACE would always be a reserved identifier (which _fl technically is not?). Not sure if _LIBCPP_ABI_NAMESPACE has any restrictions around what it should be set to. Though I guess it makes sense for anything in the STL to not use identifiers that could clash with user-defined identifiers.

1 Like
5

That’s great - thanks for that reference. I’ve now managed to hugely improve my developer experience with a single character addition…

1 Like