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

2019-01-28 Thread 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] [Release-testers] [8.0.0 Release] rc1 has been tagged

2019-01-28 Thread Sylvestre Ledru via lldb-dev


Le 24/01/2019 à 01:49, Hans Wennborg via Release-testers a écrit :

Dear testers,

8.0.0-rc1 was just tagged (from the branch at r351980).


Looks good on Debian & Ubuntu (Disco) on all supported archs (still 
waiting for mipsel & mipsel64 but I am confident):


https://buildd.debian.org/status/package.php?p=llvm-toolchain-8&suite=experimental

https://launchpad.net/ubuntu/+source/llvm-toolchain-8/1:8~+rc1-1~exp1/

Note that it is now using a stage2 build (from -7) and that -8 will NOT 
ship with Debian Buster.


I will try to dig a bit more into testsuite results.

S

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc1 has been tagged

2019-01-28 Thread Bero Rosenkränzer via lldb-dev
Hi,
working without immediately obvious regressions on OpenMandriva x86-64,
x86, aarch64 and armv7hnl.
Since our 4.0 release is imminent, 8.0 won't go in there, but it will be
our main compiler the day after the release and been cut.

Would be nice to get the admin goto patches in to enable building the Linux
kernel, but unfortunately that may be too big a change after RC?

ttyl
bero

On Thu, Jan 24, 2019, 3:50 AM Hans Wennborg via Release-testers <
release-test...@lists.llvm.org wrote:

> Dear testers,
>
> 8.0.0-rc1 was just tagged (from the branch at r351980).
>
> It took a little longer than planned, but it's looking good.
>
> Please run the test script, share your results, and upload binaries.
>
> I'll get the source tarballs and docs published as soon as possible,
> and binaries as they become available.
>
> Thanks,
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev