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

[Adrian Prantl via lldb-dev]

> On Jan 27, 2019, at 10:29 AM, David M. Lary <dmlary at gmail.com> wrote:
> 
> On Sun, Jan 27, 2019 at 10:33 AM Adrian Prantl <aprantl at apple.com <mailto: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?

I'm not perfectly sure about how exactly the type lookup operates, but I believe that this might work. You might want to try it out with just a simple hello-world example first where you cast a raw address to the list type. if that works, chances are good.

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190128/5a16ba87/attachment.html>