> On Jan 27, 2019, at 10:29 AM, David M. Lary <dml...@gmail.com> wrote: > > On Sun, Jan 27, 2019 at 10:33 AM Adrian Prantl <apra...@apple.com > <mailto: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 > > 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
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
