On Sun, Jan 27, 2019 at 10:33 AM Adrian Prantl <apra...@apple.com> wrote:
> > On Jan 26, 2019, at 6:41 PM, David M. Lary via lldb-dev 
> > <lldb-dev@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


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?

lldb-dev mailing list

Reply via email to