[lldb-dev] lldb print c++ variables from dylib loaded in Swift application

David M. Lary via lldb-dev lldb-dev at lists.llvm.org
Sun Jan 27 10:29:24 PST 2019


On Sun, Jan 27, 2019 at 10:33 AM Adrian Prantl <aprantl at apple.com> wrote:
> > On Jan 26, 2019, at 6:41 PM, David M. Lary via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> >
> > I'm writing a Swift application for MacOS that makes use of a C/C++
> > dylib from a third party to interact with a film scanner.  The
> > application uses dlopen() & dlsym() to discover and call the C wrapper
> > function for the C++ implementation.  Overall this works, but I've run
> > into the following wall while debugging an issue within the dylib
> > itself.
> >
> > While debugging I want to examine std::list <T> structures in memory
> > by address.  I am stopped deep inside the C++ code, and from what I've
> > googled, printing STL variables is possible through `frame variable`,
> > however for all of the functions within the dylib, `frame variable`
> > doesn't find any variables.
> >
> > I've tried using `expr -l c++ --
> > reinterpret_cast<std::list<int>>($rdi)`, however this just returns the
> > error: "use of undeclared identifier 'std'".
> >
> > Is there a way to cast an arbitrary address as an STL type, and print
> > it out in lldb?
>
> Casting to a std::list<int> is not a problem at all; however, the error that you are seeing is because LLDB did not find a type definition for std::list<int> in the debug information. Did you build the C++ dylib with full debug information?
>
> Long-term it should also become possible to just import the C++ "std" Clang module into LLDB to get access to all types regardless of whether they were used in the debugged program and available in debug info, but this work isn't quite finished yet.
>
> -- adrian

Adrian,

I did not build the C++ dylib, and it was not built with full debug
information; it comes from a third-party, so I don't control it.
However, from what you said, would creating an unrelated C++ dylib,
declaring the required types, and linking it into the project provide
needed types to lldb?  Would I need to use the types to ensure they're
not optimized out of the dylib?

-David


More information about the lldb-dev mailing list