Exclusively build and install LLDB?

Subprojects LLDB
1

Are there plans to add new target: lldb-only and lldb-install? There
are already similar targets for Clang.

I'm debugging LLDB on NetBSD and I'm having very bad time building
everything with debug symbols. There is also popular request from
NetBSD users to just install lldb without conflicting with Clang and LLV
M.

I was looking at Open Source distributions with a LLDB package, for
example ArchLinux is manually copying files from the build...

I would like to skip building unnecessary parts and then focus on
installing only the LLDB package... otherwise I need 64GB of
RAM+storage and a lot of time to produce new package.

2

LLDB links against clang and llvm. How would an lldb-only target work? i.e. how would you build lldb without first building clang and llvm? Unless I’m misunderstanding the purpose of your question:

As for the install, are you saying that running “ninja install” does not install lldb? If so that’s a bug and shoudl be fixed in the CMake.

3

LLDB links against clang and llvm. How would an lldb-only target
work? i.e. how would you build lldb without first building clang
and llvm? Unless I'm misunderstanding the purpose of your
question:

I don't want to build the following executables (among others):
bin/clang
bin/clang++
bin/clang-3.8
bin/clang-check
bin/clang-cl
bin/clang-format
bin/git-clang-format

I've found that to some extend I can emulate it with:
ninja/make lldb lldb-mi

I would like to have a target lldb-only, building all LLDB targets
needed to install the full distribution and to perform builtin tests.

As for the install, are you saying that running "ninja install"
does not install lldb? If so that's a bug and shoudl be fixed in
the CMake.

ninja/make install does its job installing LLDB properly.

My complain is that it's not possible (to my knowledge) to stop
installing Clang and LLVM sets.

I don't want to populate my system with the following example files:
bin/clang*
bin/llvm*
include/clang-c/
include/clang/
include/llvm/

Another good reason, besides time and space optimization is that among
others pkgsrc isn't designed to produce multiple packages from a
single meta-file (in a format of BSD Makefile in pkgsrc) with rules
specified to build a piece of software.

It's convenient to users to ship with separated prebuilt packages with
Clang, LLVM, LLDB etc. For now users who installed Clang from pkgsrc
won't be able to install LLDB from pkgsrc-wip (containing prebuilt
package with LLDB from HEAD/master/trunk of the debugger).

For now there seems to be need to go for walk-around similar to
ArchLinux [1]:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=lldb-svn

Additionally I've optimized my build with
- -DLLVM_TARGETS_TO_BUILD="X86" and it significantly reduced the
resource usage! I will happily accept more suggestions how to tune it
further.

My current Makefile is here:
http://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob_plain;f
=lldb-git/Makefile
GH mirror:
https://github.com/NetBSD/pkgsrc-wip/blob/master/lldb-git/Makefile

Thanks!

4

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

5

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.

6

For the cross reference.

A patch allowing to build (tested on NetBSD) out of sources pushed to
review: reviews.llvm.org/D15067

7

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.

8

I think you have misunderstood our intentions here.

Kamil, correct me if I am wrong, but I don't think we are talking
about building lldb against a different version of clang. What we want
is just to be able to build and link lldb against an already-built
clang (of the same version). This is quite useful when you (as a
distribution maintainer) want to provide prebuilt packages. So, for
example you can have a "clang" and an "lldb" package. Users wishing to
install clang, just get the first one, while someone installing lldb
will get the correct clang package pulled automatically. I believe the
easiest way to build these packages is to use the standalone mode of
lldb (which already exists, and some people use that).

hope that makes sense,
pl

9

Yes, that concept came out in the thread. I just wanted to make sure there wasn’t also a desire to park on a version of llvm/clang, and if so, that the path there is not pleasant and definitely not intended to be supported on top of tree svn/trunk.

Thanks for clarifying!

-Todd

10

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

11

It seems that the only library / header out of public includes is for
handling raw (in C) Regular Expressions. I have a work-in-progress
code switching to public llvm::Regex instead. Other then that, there
are minor changes in CMake.

I'm ignoring autoconf framework since it's marked to be abandoned.

12

Compatibility with wide range of LLVM or Clang releases is out of scope.