[lldb-dev] Exclusively build and install LLDB?

Wed Dec 2 10:36:09 PST 2015

Todd is right, at runtime lldb does need to find some of the clang include files in order to build modules for its own purposes.  On an OS X install, these headers are put in:

LLDB.framework/Resources/Clang

and are:

 > ls
./			avx512vlbwintrin.h	lzcntintrin.h		stdatomic.h
../			avx512vlintrin.h	mm3dnow.h		stdbool.h
Intrin.h		avxintrin.h		mm_malloc.h		stddef.h
__stddef_max_align_t.h	bmi2intrin.h		mmintrin.h		stdint.h
__wmmintrin_aes.h	bmiintrin.h		module.modulemap	stdnoreturn.h
__wmmintrin_pclmul.h	cpuid.h			nmmintrin.h		tbmintrin.h
adxintrin.h		emmintrin.h		pmmintrin.h		tgmath.h
altivec.h		f16cintrin.h		popcntintrin.h		tmmintrin.h
ammintrin.h		float.h			prfchwintrin.h		unwind.h
arm_acle.h		fma4intrin.h		rdseedintrin.h		vadefs.h
arm_neon.h		fmaintrin.h		rtmintrin.h		varargs.h
avx2intrin.h		ia32intrin.h		shaintrin.h		wmmintrin.h
avx512bwintrin.h	immintrin.h		smmintrin.h		x86intrin.h
avx512erintrin.h	iso646.h		stdalign.h		xmmintrin.h
avx512fintrin.h		limits.h		stdarg.h		xopintrin.h

Other than that, lldb shouldn't need to install any other clang bits for its own purposes - and on OS X at least lldb only installs itself and not any of the clang binaries, so in practice this can be made to work.

Also, building lldb requires a lot of clang/llvm headers that I don't think get installed in the normal course of things.  So I'm not sure how easy it is going to be to build lldb against an installed llvm/clang.  I couldn't tell for sure whether this was another of your goals, but it may take a fair bit of monkeying around if you want to do things this way.

Jim

> On Dec 2, 2015, at 8:19 AM, Todd Fiala via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Sorry for being late the the party here.
> 
> Sean Callanan and some of the other members can comment more on this, but LLDB's expression parser for C/C++ is going to need access to the clang include headers, so somehow lldb has to be able to find them.  Out of tree llvm/clang usage is certainly possible as others have pointed out.  Using that as the one way it is done, though, is likely to lead to pain.  Parts of lldb's source will adjust as needed when the API surface area of LLVM or clang changes.  It may not be happening quite as frequently as it had say 2 or 3 years ago, but it definitely happens.  So my expectation would be that if you decouple lldb from llvm/clang (i.e. let them drift), sooner or later you will get bitten by that.  Particularly when things like clang modules and whatnot come along and actually require different logic on the lldb side to deal with content generated on the clang/llvm side.  Once expression evaluation is potentially compromised (due to the drift), I suspect the lldb experience will degrade significantly.
> 
> On Sun, Nov 29, 2015 at 9:28 PM, Kamil Rytarowski via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 27.11.2015 00:57, Kamil Rytarowski via lldb-dev wrote:
> > On 11/23/15 10:28, Pavel Labath wrote:
> >> I believe that for purposes of building distribution packages you
> >>  should use the out-of-tree mode of building lldb. This means,
> >> you build llvm and clang separately, and then point your LLDB
> >> build to their installation path with LLDB_PATH_TO_LLVM_BUILD and
> >>  LLDB_PATH_TO_CLANG_BUILD variables. This way you can avoid
> >> building llvm/clang twice, you can have a separate package for
> >> each logical component of llvm and you can make lldb optional for
> >> your users (e.g. have only clang installed normally, if user
> >> chooses to install lldb, it will automatically pull in clang if
> >> needed). In this mode "make install" should install only the lldb
> >> components, which should be correctly linked to the
> >> already-installed llvm libraries.
> >
> >> That said, I can't guarantee that this mode will work for you
> >> out-of-the-box. We occasionally get patches to fix it up, but I
> >> don't know anyone who is using it extensively. However, I think
> >> this would be the best way forward for you and I'm prepared yo
> >> help you out if you choose to go that way.
> >
> >> What do you think about that?
> >
> >> pl
> >
> >
> > Thank you for your note on this mode. I was trying to prototype a
> > set of packages with: sources of llvm and clang, build dirs of llvm
> > and clang and installations of llvm and clang.
> >
> > Badly this approach doesn't work with pkgsrc, as this framework
> > contains various checks against using sources, headers, executables
> > or other files out of the build tree. Packaging sources and build
> > tree triggers errors with moving invalid files into ${DESTDIR}.
> > Everything is wolkaroundable, but I think it's not the correct way
> > of handling it.
> >
> > I've checked that libcxx, cfe and compiler-rt ship with mechanism
> > to build against preinstalled LLVM. I will try them out and I'm
> > going to prepare new pkgsrc packages using this approach. Then I
> > will try to research doing the same with LLDB, exporting needed
> > libraries and headers for the compiler withing llvm and lldb.
> 
> For the cross reference.
> 
> A patch allowing to build (tested on NetBSD) out of sources pushed to
> review: reviews.llvm.org/D15067
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJWW96JAAoJEEuzCOmwLnZsCLAP/0LrhGlzivOjtykjW3ywvXia
> wtZRLYsPwsNBJJERdOGVOJVPovnT02H+Bf1a4eDf0dJXbecklyfiupNfthlvFr9l
> PxCLZI4GQPLcP+jqWbhcFRdhzFeyEnLLy0Wjt1MNYG0s3m2u4jJM2ViNLA10/kwS
> XX82e2K7q5MUb51MMEJ09ufpYyGff7XmjVE78w1ekfNSRlKFMc0DNBsaIx4oKZfM
> G2IUtRNL59ad2pkw/xA3D2OPtoTk7+a2jjF8Z4nYY6kUSyBPUlCYrjyfavVCreR6
> 6Zo2E3lkkEb6PSIfb57RlMtxBIfmIBjv5w6OcFjSK6aYvffY9IMgyBJvGbdA+Ee7
> DlCFZax25eJPglEnfzAI2XOHOUQJtDwhb45N+XWshLfUax2e52KJvj9nq9J8pOse
> AC00qRQN+KTZsil43dlOfEn5m18mJ9o+CohK5eLMoTnS9QdtP8OEv72zGjOsSqrx
> vXDx01ziuQRCgsJ+niZXHgRLA65hxD5XgSGEBzr5prRLtU6q6V/HpYOsC46+pySc
> ibLrRWHnaeBVJknwz11iBo4gBZRk3lGhi5aTfu9+kcX6ylKSn2nn34+HGHr//FZi
> SrKcb3z7WikAR0c9cHBNOnwbro6o08j8zUE2l2S08risLRDDu01KBo3yFebjHz8D
> vQqFJNDkRLywQbXezcjB
> =7C7K
> -----END PGP SIGNATURE-----
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> 
> -- 
> -Todd
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev