Aktualizacja w temacie #mitmproxy, czyli jak nie zamierzałem spędzać soboty.

Poprzednio: https://pol.social/@mgorny/114364801169118580

Tak więc:

1. Z pomocą osoby nickiem vadorovsky, dowiedziałem się, że jak dam --no-default-features, to bpf-linker użyje systemowego LLVM, i w ten sposób pozbyłem się problemów nr. 2 i 4.
2. #LLVM 20 nadal się sypie, ale jakimś cudem wtorkowy snapshot LLVM 21 działa.
3. Musiałem wrzucić btfdump na potrzeby testów, ale teraz wszystkie przechodzą.
4. Zmarnowałem godziny na budowanie mitmproxy-linux, ale w końcu znalazłem sposób. Otóż, okazuje się, że muszę wywalić logikę budowania binarek w formacie bpf z tej paczki, zbudować je ręcznie z poprawną wartością RUSTFLAGS, a potem połączyć to w całość. https://github.com/mitmproxy/mitmproxy/issues/7663
5. Problem z rustc-build-sysroot jest jeszcze gorszy w mitmproxy-linux.
6. Testy mitmproxy-linux segfaulcą (jak to #RustLang).
7. Ale jak już wszystko poinstaluję, to testy mitmproxy przechodzą.

Więc zostaje mi wymyślić, co zrobić z tymi segfaulcącymi testami, i myślę, że nowa wersja mitmproxy może wylądować w #Gentoo. Przypięta do pojedynczej wersji kompilatora Rusta, ale zawsze coś.

#mitmproxy update AKA not how I imagined spending my Saturday.

Previous post: https://social.treehouse.systems/@mgorny/114364774872404427

So:

1. With help of vadorovsky, I've learned that I need to pass --no-default-features, and then it uses system LLVM which resolves problems 2. and 4.
2. #LLVM 20 still fails on that assertion, but Tuesday's LLVM 21 snapshot works fine.
3. I also needed to package btfdump for bpf-linker's tests but I was finally able to get them to pass.
4. After spending hours trying to figure out mitmproxy-linux build failures, I've finally found a way to build it: I need to remove upstream's logic for building bpf binaries, build them manually with correct RUSTFLAGS, and then build the whole thing. https://github.com/mitmproxy/mitmproxy/issues/7663
5. rustc-build-sysroot crate problem is even worse in mitmproxy-linux.
6. mitmproxy-linux's tests segfault (yeah, #RustLang).
7. But still, with the packages built, I can get tests to pass on mitmproxy itself.

So yeah, if I can only figure out what to do about these segfaulting tests, I think we can get new mitmproxy version into #Gentoo. Pinned to one Rust version, but that's better than nothing, I guess.

Zmarnowałem kolejną godzinę na użeranie się z próbą dodania bpf-linker / nowej wersji #mitmproxy do #Gentoo. Podsumowując:

1. Wymaga funkcji, dostępnych wyłącznie w eksperymentalnych wersjach kompilatora #RustLang. Można to obejść, ustawiając RUSTC_BOOTSTRAP=1. https://github.com/aya-rs/bpf-linker/issues/250
2. Wymaga innych wersji kilku bibliotek poprzez zależność aya-rustc-llvm-proxy, jakimś cudem. Można to albo rozwiązać dodając do ebuilda owe wersje, albo usuwając z wypakowanego archiwum plik `Cargo.lock`.
3. Wymaga `compiler_builts` poprzez zależność rustc-build-sysroot. Co ciekawe, konkretna wersja jest przypięta wewnątrz biblioteki standardowej Rusta, więc musiałbym dodać odpowiednią wersję zależności dla każdej obsługiwanej wersji kompilatora!
4. Ma własną logikę wyszukiwania biblioteki #LLVM, która porusza się po PATH i podmienia `bin` na `lib`. Tak, na katalog z 32-bitowymi bibliotekami. Da się to obejść, ustawiając LD_LIBRARY_PATH. https://github.com/aya-rs/bpf-linker/issues/270
5. Nawet jak obejdę wszystkie inne problemy, to koniec konców się sypie na użyciu LLVM. Zgaduję, że nikomu nie przyszło do głowy użyć do testów LLVM z kontrolą poprawności użycia API. https://github.com/aya-rs/bpf-linker/issues/271

No cóż, taka jakość programów pisanych w Ruście. Co gorsza, te wszystkie problemy dotyczą nie budowania, a uruchamiania bpf-linkera — więc tak czy siak, instalowalibyśmy program, który w ogóle nie działa bez dodatkowych obejść.

Spent another hour on trying to get bpf-linker / new #mitmproxy into #Gentoo. To summarize:

1. It needs features from nightly #RustLang compiler at runtime. This can be worked around via setting RUSTC_BOOTSTRAP=1. https://github.com/aya-rs/bpf-linker/issues/250
2. It needs different pinned versions of some libraries via aya-rustc-llvm-proxy somehow. This can be solved via manually adding more crates to the ebuild (sigh) or just removing the extra `Cargo.lock` from the crate.
3. It needs `compiler_builtins` crate via rustc-build-sysroot crate. Funny enough, the version is pinned by Rust standard library itself, so I need to add a specific crate for every supported Rust compiler version!
4. It uses a homemade logic to find #LLVM library, which iterates over PATH and replaces `bin` with `lib`. Yes, with 32-bit libdir. It can be worked around via setting LD_LIBRARY_PATH. https://github.com/aya-rs/bpf-linker/issues/270
5. Even after working around all these issues, it crashes by triggering an assertion in LLVM. I guess nobody bothered testing with assertions enabled, as usual. https://github.com/aya-rs/bpf-linker/issues/271

So yeah, that's your Rust quality. On top of that, let's not forget that this is all runtime issues — like we would be installed a bpf-linker executable that's nonfunctional unless you apply workarounds.

#EuroLLVM to świetna okazja, by porozmawiać o społeczności #LLVM. Nie, nie na konferencji.

Jeżeli kiedykolwiek mieliście jakiekolwiek wątpliwości co do tego, jaki stosunek do wolontariuszy ma owa społeczność, wystarczy spojrzeć na ceny biletów. Który wolontariusz wyrzuci $750 z własnej kieszeni za wstęp?!

No ale dobra, znamy swoje miejsce. My jesteśmy od tego, żeby poświęcać swoje weekendy na naprawianie tego, co państwo korporacjusze zepsują w tygodniu. A następnie proszenia się, żeby przejrzeli nasze poprawki, zanim zepsują kolejną rzecz. A w tym czasie jaśnie wielmożni będą radzić, jak zgotować nam jeszcze gorszą przyszłość.

https://llvm.swoogo.com/2025eurollvm

#EuroLLVM is a good opportunity to talk of the #LLVM community. No, not at the conference.

Because if you ever were wondering what LLVM project's attitude towards its volunteer contributors is, just look at the ticket prices. I mean, which volunteer would spend $750 on a conference ticket?!

But yeah, we know our place. It's to spend weekends fixing what corporate contributors broke through the week, then beg them to actually review our fixes before they break more. And in the meantime, our gracious lords will debate how to mess up our future even more.

https://llvm.swoogo.com/2025eurollvm

2025 and clang-format still can't enforce a space before function calls https://releases.llvm.org/20.1.0/tools/clang/docs/ClangFormatStyleOptions.html #llvm #clang #format

One of the reasons I'm still using GitHub for a lot of stuff is the free CI, but I hadn't really realised how little that actually costs. For #CHERIoT #LLVM, we're using Cirrus-CI with a 'bring your own cloud subscription' thing. We set up ccache backed by a cloud storage thing, so incremental builds are fast. The bill for last month? £0.31.

We'll probably pay more as we hire more developers, but I doubt it will cost more than £10/month even with an active team and external contributors. Each CI run costs almost a rounding-error amount, and that's doing a clean (+ ccache) build of LLVM and running the test suite. We're using Google's Arm instances, which have amazingly good price:performance (much better than the x86 ones) for all CI, and just building the x86-64 releases on x86-64 hardware (we do x86-64 and AArch64 builds to pull into our dev container).

For personal stuff, I doubt the CI that I use costs more than £0.10/month at this kind of price. There's a real market for a cloud provider that focuses on scaling down more than on scaling up and made it easy to deploy this kind of thing (we spent far more money on the developer time to figure out the nightmare GCE web interface than we've spent on the compute. It's almost as bad as Azure and seems to be designed by the same set of creatures who have never actually met a human).

A new #blog post appears!

I built a native GCC 14.2.0 for Mac OS X 10.4 Tiger PowerPC.

https://briancallahan.net/blog/20250329.html

Calculate Throughput with LLVM's Scheduling Model
https://myhsu.xyz/llvm-sched-interval-throughput/
by @mshockwave
#LLVM

I do wish #llvm and #rustlang compiler toolchains took less time to build.

Announcing the LLVM backend for MoonBit, hitting 8x faster performance than Java in FFT benchmarks and enabling out-of-the-box debugging! #MoonBit #LLVM
https://www.moonbitlang.com/blog/llvm-backend

#FreeBSD enables the full suite of #llvm compiler toolchain components for the base operating system: https://cgit.FreeBSD.org/src/commit/?id=1cae7121c667d9caf205832cf45fd02af3157e6f

Great to see.

Wygląda na to, że ktoś stara się, żeby Flanga dało się skompilować. No wiecie, jak ktoś nie ma po 16G RAM-u na każdy proces kompilatora.

https://github.com/llvm/llvm-project/pull/130600

FYI, someone's actually putting an effort to try to make #Flang compileable. You know, without needing 16G RAM for a single compiler job.

https://github.com/llvm/llvm-project/pull/130600

Healthy Competition With #GCC15 vs. #LLVM #Clang20 Performance On #AMD #Zen5
With some codebases/workloads there can be strong advantages at time for one compiler over the other, but at a high level the #GCC and Clang #compiler performance is extremely tight with recent versions and on modern #x86_64 hardware.
https://www.phoronix.com/review/clang20-gcc15-amd-znver5

Chris Lattner is a genius. #Swift #LLVM #Clang #mojo