lldb missing from mac and linux packages

[cristianadam]

If I search after the clang++ compiler I can find:

$ find . | grep -i /bin/clang++
./llvm-mingw-20230730-ucrt-macos-universal/bin/clang++
./llvm-mingw-20230730-ucrt-ubuntu-20.04-x86_64/bin/clang++
./llvm-mingw-20230730-ucrt-x86_64/bin/clang++.exe

The same for the ld.lld linker:

$ find . | grep -i /bin/ld.lld
./llvm-mingw-20230730-ucrt-macos-universal/bin/ld.lld
./llvm-mingw-20230730-ucrt-ubuntu-20.04-x86_64/bin/ld.lld
./llvm-mingw-20230730-ucrt-x86_64/bin/ld.lld.exe

But for the lldb debugger only the Windows package contains it:

$ find . | grep -i /bin/lldb
./llvm-mingw-20230730-ucrt-x86_64/bin/lldb-argdumper.exe
./llvm-mingw-20230730-ucrt-x86_64/bin/lldb-instr.exe
./llvm-mingw-20230730-ucrt-x86_64/bin/lldb-mi.exe
./llvm-mingw-20230730-ucrt-x86_64/bin/lldb-server.exe
./llvm-mingw-20230730-ucrt-x86_64/bin/lldb-vscode.exe
./llvm-mingw-20230730-ucrt-x86_64/bin/lldb.exe

I expected the debugger to be present into the linux and mac releases. Could be useful for doing MiniDump core analysis without having to have a Windows machine.

[mstorsjo]

Right, this was one of the things that were sacrificed in the transition to building the releases with github actions (along with clang-tools-extra in the unix based packages), mentioned in #336. In the 16.0.0 release (which was built manually), I'm fairly sure LLDB was available on all platforms.

It's good input to hear that LLDB is wanted in those packages too (when it was included, I mostly got the question about why it was there).

I guess it could be possible to add LLDB into the build on Github without exceeding the per-job time limits; each pipeline run will take slightly longer of course, but I guess it can be tolerated if there's a concrete desire to have LLDB included there.

[cristianadam]

To speed up things you could use some caching via ccache. You can either use the caching mechanism of GitHub Actions or just archive the .ccache directory, store it as an artifact and look at previous jobs for previous .ccache archives.

This is what we do at Qt Creator https://github.com/qt-creator/qt-creator/actions

Besides loading of MiniDump core files I can think of remote debugging from a Linux/mac machine to a Windows one.

You can easily get a Windows 11 VM machine from https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ but might not want to develop on a Windows machine, which has slow file access, but deploy and remote debug an application.

This is where you need a lldb binary on your linux / mac machine.

[mstorsjo]

To speed up things you could use some caching via ccache. You can either use the caching mechanism of GitHub Actions or just archive the .ccache directory, store it as an artifact and look at previous jobs for previous .ccache archives.

FWIW, there's usually not much benefit from that when I'm just building the LLVM projects nightly; almost every day (except for some day on the weekends), enough common headers are changed so that essentially every single file needs to be rebuilt anyway. But I guess it could be useful for speeding up multiple rebuilds of the same LLVM version - possibly. (For local development of LLVM, ccache is quite useful though.) Caching is useful for the first stage in the build process (building LLVM with a system provided toolchain), but for the second stage, building code with the just-built Clang, we can't really benefit from caching since we're using a brand new compiler each time and we need to test that it actually ends up right when built with this exact compiler.

This is what we do at Qt Creator https://github.com/qt-creator/qt-creator/actions

Thanks for the pointer!

Besides loading of MiniDump core files I can think of remote debugging from a Linux/mac machine to a Windows one.

You can easily get a Windows 11 VM machine from https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/ but might not want to develop on a Windows machine, which has slow file access, but deploy and remote debug an application.

This is where you need a lldb binary on your linux / mac machine.

Yep, these are all good usecases.

[mstorsjo]

I pushed 8b01a13 and a861db9 now, so LLDB should now be included in the linux and macos packages in coming releases and nightly builds.

[cristianadam]

Even though Python is needed for Qt Creator's lldb usage, Qt Creator is getting also support for the Debug Adapter Protocol (DAP) and might not be such a big deal.

[mstorsjo]

Even though Python is needed for Qt Creator's lldb usage, Qt Creator is getting also support for the Debug Adapter Protocol (DAP) and might not be such a big deal.

Ok, great!

Yeah, for the Windows packages, we bundled a (minimal) copy of python. For macOS, it is messy to get a system-provided version of Python to rely on, and for Linux I'd prefer not to (even if it's probably easy to rely on the base distribution) since it makes the tools less portable across distributions. And I wouldn't want to spend time/effort/space on bundling a selfcontained copy of Python in the unix packages.

[mstorsjo]

The later LLVM 17.x based releases candidates, and the stable releases, should include LLDB in the unix based builds now as well, so I think this issue is done.

[cristianadam]

I've forgotten that the lldb doesn't come with python 'batteries' for macOS.

I was trying to configure a LLVM MinGW toolchain with Qt Creator and CMakePresets with the ability to register a debugger, and then noticed that python bindings are missing... 😔

#430 worked fine in helping me test https://bugreports.qt.io/browse/QTCREATORBUG-29880 😀

[cristianadam]

As it turns out lldb-dap can work without Python bindings - e.g. type summary add QString --summary-string ${var.d.ptr}, but if you want to have pretty printers that are a bit more advanced, you still need the Python bindings.

See https://lldb.llvm.org/use/variable.html#python-scripting and https://lldb.llvm.org/use/variable.html#synthetic-children

For a moment I thought that one could use the Lua scripting language, that would be easier to compile and distribute. But if we look at https://github.com/llvm/llvm-project/tree/main/lldb/source/Plugins/ScriptInterpreter we can see that the Lua plugin does not implement the same things that the Python plugin is implementing 😔

[mstorsjo]

I guess if this really is desired, the way forward would be to build a minimal cpython install that we bundle along with the package, just like we do for Windows. I guess most of the groundwork for this already has been done, and it could mostly be a case of adapting things for doing the bundling/packaging for Linux/macOS.

[longnguyen2004]

the way forward would be to build a minimal cpython install that we bundle along with the package

The build steps are the same, we just need to swap cpython-mingw with the original cpython (of course ignoring potential issues like dylib/so relocation, which I have no clues about, even though I'm also using Linux...)

[mstorsjo]

the way forward would be to build a minimal cpython install that we bundle along with the package

The build steps are the same, we just need to swap cpython-mingw with the original cpython (of course ignoring potential issues like dylib/so relocation, which I have no clues about, even though I'm also using Linux...)

Ah, right, one might need to mess around with setting rpaths or similar, to get it work properly self-contained.

Anyway, to be clear, this isn't something I'm actively seeing myself picking up in the near future, but I wouldn't mind if someone else wants to pick it up.

(Totally unrelated side note; compiling Python produces extremely much log output. When doing it as part of a GitHub Actions job, it produces so much output that GitHub Actions practically stops handling realtime log output from the remainder of that job, although the log output is available afterwards. It's annoying to the point that I've considered, but not yet implemented, splitting out building python into a separate step - it'd complicate the scripts, but would make it more possible to observe the later build of LLVM while it still is running.)

[longnguyen2004]

compiling Python produces extremely much log output

Is it mostly from make? If yes then maybe we can redirect stdout to /dev/null and call it a day?
Also I don't know if tests are also built as part of the default target, we can probably find a way to not build tests if that's the case.

[mstorsjo]

compiling Python produces extremely much log output

Is it mostly from make? If yes then maybe we can redirect stdout to /dev/null and call it a day?

Yes - but that's not ideal either... If anything fails, we're entirely blind and don't even have an initial clue about what went wrong. Ideally, we'd do e.g. what ninja does, silence printing the actual commands by default, but print the failing command if something failed. But IIRC the regular make output is only one part of it; most of it is their own python based compilation of modules and such.

We could of course pipe the output to a file, and print that if something failed. But then we also lose the realtime aspect of seeing what's happening while compiling, getting some feel of what's happening.

Also I don't know if tests are also built as part of the default target, we can probably find a way to not build tests if that's the case.

If that's possible, that'd be great!

[longnguyen2004]

There is --disable-test-modules, which will disable building test modules (see https://github.com/msys2-contrib/cpython-mingw/blob/mingw-v3.11.9/Doc/using/configure.rst#install-options)

I also found $$quiet, which is triggered by passing -s to make, but I don't know if that will affect the quality of the output or not (which is the "entirely blind" part)

[mstorsjo]

There are --disable-test-modules, which will disable building test modules (see https://github.com/msys2-contrib/cpython-mingw/blob/mingw-v3.11.9/Doc/using/configure.rst#install-options)

Thanks, this cuts down the number of line quite significantly, from 21539 lines of log output, to 14653 lines. (This includes building libffi and cpython twice each.)

I also found $$quiet, which is triggered by passing -s to make, but I don't know if that will affect the quality of the output or not (which is the "entirely blind" part)

It does indeed affect the quality of the output quite a bit - the python part of the build runs entirely blind - but the output still is 13303 lines (libffi, and the configure parts, and other bits). But it reduces the size of the log a bit - most of the omitted lines are fairly long; cutting down the log size from 1.5 MB at this point (2.3 MB before --disable-test-modules) to 1.2 MB. But I'm not sure if it's worth the reduction in output quality - I'll consider it.

--disable-test-modules should be a big improvement at least; thanks!

[mstorsjo]

FYI, I tried to break down the different contributions to the log output from building python, and got the following numbers. Initially, before a78eb49, the amount of log output looked like this:

    146 libffi/build/log-configure
    101 libffi/build/log-make
     57 libffi/build/log-make-install
    912 cpython-native/build/log-configure
    569 cpython-native/build/log-make
   8779 cpython-native/build/log-make-install
    151 libffi/build-x86_64-w64-mingw32/log-configure
     84 libffi/build-x86_64-w64-mingw32/log-make
     43 libffi/build-x86_64-w64-mingw32/log-make-install
    724 cpython-mingw/build-x86_64-w64-mingw32/log-configure
   1090 cpython-mingw/build-x86_64-w64-mingw32/log-make
   8843 cpython-mingw/build-x86_64-w64-mingw32/log-make-install
  21499 total

After a78eb49, it looks like this:

    146 libffi/build/log-configure
    101 libffi/build/log-make
     57 libffi/build/log-make-install
    912 cpython-native/build/log-configure
    523 cpython-native/build/log-make
   7188 cpython-native/build/log-make-install
    151 libffi/build-x86_64-w64-mingw32/log-configure
     84 libffi/build-x86_64-w64-mingw32/log-make
     43 libffi/build-x86_64-w64-mingw32/log-make-install
    724 cpython-mingw/build-x86_64-w64-mingw32/log-configure
   1009 cpython-mingw/build-x86_64-w64-mingw32/log-make
   4380 cpython-mingw/build-x86_64-w64-mingw32/log-make-install
  15318 total

If adding -s to the python make invocations, we get the following numbers:

    146 libffi/build/log-configure
    101 libffi/build/log-make
     57 libffi/build/log-make-install
    912 cpython-native/build/log-configure
     34 cpython-native/build/log-make
   7041 cpython-native/build/log-make-install
    151 libffi/build-x86_64-w64-mingw32/log-configure
     84 libffi/build-x86_64-w64-mingw32/log-make
     43 libffi/build-x86_64-w64-mingw32/log-make-install
    724 cpython-mingw/build-x86_64-w64-mingw32/log-configure
    471 cpython-mingw/build-x86_64-w64-mingw32/log-make
   4235 cpython-mingw/build-x86_64-w64-mingw32/log-make-install
  13999 total

Out of the 4000 lines in cpython-mingw/build-x86_64-w64-mingw32/log-make-install, 972 are of the type

/usr/bin/install -c -m 644 ../Lib/__future__.py /home/martin/clang-python-test/python/lib/python3.11

2874 are of this type:

Compiling '/home/martin/clang-python-test/python/lib/python3.11/concurrent/futures/process.py'...

And 207 are of this type:

Listing '/home/martin/clang-python-test/python/lib/python3.11/__phello__'...

[longnguyen2004]

Compiling '/home/martin/clang-python-test/python/lib/python3.11/concurrent/futures/process.py'...
Listing '/home/martin/clang-python-test/python/lib/python3.11/__phello__'...

These lines come from compileall.py, which is run 6 times (!) when doing make install. The script does support a quiet flag, but it's not that easy to add the quiet flag in without resorting to patching (or otherwise dirtying) the Makefile. Maybe we can do some sed magic before configuring?