What's your favorite way of compiling stuff to assembly (preferably supporting a few different target archs), but other than LLVM?
Are there any actual sensible alternatives now?
#llvm
Remarkable how easy it is to inspect different levels of #codegen in #JuliaLang - from intermediate representations, through #LLVM IR, to native, e.g.:
```
julia> @code_llvm 1+2
; Function Signature: +(Int64, Int64)
; @ int.jl:87 within `+`
define i64 @"julia_+_735"(i64 signext %"x::Int64", i64 signext %"y::Int64") #0 {
top:
%0 = add i64 %"y::Int64", %"x::Int64"
ret i64 %0
}
```
But there is no `@code_source` macro (should return, e.g., `1 + 2`) 😊
(Most 👍 in repo): https://github.com/JuliaLang/julia/issues/2625#issuecomment-498840808
Wyolbrzymione:
#Intel: w końcu obsługujemy #LLVM 16!
Użytkownik: u mnie się nie kompiluje z LLVM 16.
Intel: u nas działa, potrzebujesz tej łatki.
Użytkownik: ale ta łatka sprawia, że LLVM 15 buduje się jako wersja 16.x.
Intel: …
Użytkownik: …
Intel: jak już mówiliśmy, wspieramy LLVM 16!
https://github.com/intel/intel-graphics-compiler/issues/289#issuecomment-2845719524
Exaggerated:
#Intel: we finally support #LLVM 16!
User: but it fails to build against LLVM 16.
Intel: it builds for us, you just need this patch.
User: but this patch makes LLVM 15 build as 16.x.
Intel: …
User: …
Intel: so yes, we support LLVM 16 now!
https://github.com/intel/intel-graphics-compiler/issues/289#issuecomment-2845719524
AGPX Releases “C64 Game Maker” – Create Commodore 64 Games Using BASIC and C++
#C64GameMaker #Commodore64 #RetroDev #BASIC #LLVM #Oscar64 #SIDSound #AGPX #RetroComputing #8BitGaming
https://theoasisbbs.com/agpx-releases-c64-game-maker-create-commodore-64-games-using-basic-and-c/?feed_id=3083&_unique_id=681375831f600
[Перевод] Golang на PlayStation 2
Мне всегда хотелось творить какую-нибудь дичь с консолями. Не знаю почему, но меня всегда привлекала идея реализовывать на устройствах неожиданные возможности. Это относится и к PlayStation 2 , выпущенной Sony в 2000 году. Sony, пожалуйста, не подавайте в суд на меня за этот пост. Перейдём сразу к делу: я хочу научиться запускать код на консолях (подробнее о том, зачем это нужно, я расскажу в другом посте). Обычно это делается на языках низкого уровня, но сегодня мы можем проще и удобнее работать с языками наподобие Go . Поэтому я подумал: почему бы и нет? Поискав онлайн, я не нашёл простого решения, поэтому взялся за эту задачу самостоятельно.
Mark your calendars! Next #LLVM #Meetup #Darmstadt happening on May 28th 2025, starting 7pm.
We will have three shorter talks to cover a variety of cool topics around #compilers and #tooling support. \o/
Check out the agenda and RSVP at https://www.meetup.com/llvm-social-darmstadt/events/307546813
Status: planning a new analysis for #LLVM.
https://gist.github.com/artagnon/b9524935f7f9d355eff082469bc72d03
Exploiting Undefined Behavior in C/C++ Programs for Optimization: A Study on the Performance Impact
Someone did a study on the performance impact of exploiting undefined behaviour in C/C++: https://web.ist.utl.pt/nuno.lopes/pubs/ub-pldi25.pdf
> "[...] we demonstrate that, for the benchmarks and UB categories that we evaluated, the end-to-end performance gains are minimal. Moreover, when performance regresses, it can often be recovered through small improvements to optimization algorithms or by using link-time optimizations."
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.
@mgorny The #LLVM Foundation is non-profit, and the high ticket prices are somewhat unfortunate: the venue wasn’t cheap, and we insist on high-quality recordings. I agree that many of the corporate contributors are irresponsible, but there’s also a good share of people on retainers, who pretty much get to do what they want. Not sure I’d classify the major people (Florian, Nikita, Matt, Craig) as “corporate contributors”.
No mention of Cygnus? 🧐
“What The Hell Is A Target Triple?”, Miguel Young de la Sota (https://mcyoung.xyz/2025/04/14/target-triples/).
Via HN: https://news.ycombinator.com/item?id=43696756
On Lobsters: https://lobste.rs/s/ofacpc/what_hell_is_target_triple
Watch Full-stack Linux dev fix #LLVM. #Clang & #Rust for #Mesa3D and other SPARC details! https://www.youtube.com/watch?v=UV7wYDXKBPs
#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ść.
#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.
ELD: A new open-source embedded linker tool for embedded systems
https://www.qualcomm.com/developer/blog/2025/04/eld-new-open-source-embedded-linker-tool-for-embedded-systems
#ycombinator #Open_Source #LLVM
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst