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@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@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@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
> --
> -Todd
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
