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

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

[David M. Lary via lldb-dev]

On Sun, Jan 27, 2019 at 10:33 AM Adrian Prantl  wrote:
> > On Jan 26, 2019, at 6:41 PM, David M. Lary via lldb-dev 
> >  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  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>($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 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 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Adrian Prantl via lldb-dev]

> On Jan 26, 2019, at 6:41 PM, David M. Lary via lldb-dev 
>  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  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>($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 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 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev