@gafanhoto as melhoras!

:woozy_hug:

Building a Debugger is now officially released!

It guides you through writing a whole native x64 debugger from scratch, dispelling all the magic and teaching you a ton about operating systems as it goes.

Even if you don't care about writing a debugger, you can read it to your cat.

S'acaba la setmana eterna en La Corunya i, estant al tren, la meua amiga californiana em diu que ha esborrat uns quants xats de Signal i que no li escriga res sobre política en les pròximes 24h, perquè ha d'entrar als EUA i potser li miren el mòbil. Però no li digueu feixisme encara, eh?

@gafanhoto As duas Espanhas! 🟩 🟥

🤭

@gafanhoto Portugal está aún riéndose de esta marca española 😆

On my quasi-blog:

"In which I have Opinions about parsing and grammars"

https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/parsing/

A collection of semi-connected rants about context-free grammars, parser generators, and the ways in which they aren’t quite as useful as I’d like them to be.

@gafanhoto 😁

Turns out that the latest toolset for RH8 (with GCC 14 and clang 19) fixes this by manually expanding the soft link `lib` into `/usr/lib` in the `--gcc-install-dir` flag they pass through the clang configuration file.

This makes clang emit the expanded paths in the dependency file and ninja syntactic canonicalisation works again.

So, for me, updating the Rocky Linux 8 container I use solves my problems.

@asb I recall reading your post but I failed to realise the issue you described was the same I hit today!

@rofirrim I've lost a bunch of time on this rabbit hole too - a good chunk of it due to "things can't really be this broken, it must be me". I discuss a bit here https://muxup.com/building-testing-and-distributing-llvm-clang-and-friends#single-stage-cross-build

Indeed, hacking ninja to use glibc's realpath does the right thing.

Looks like clang cannot really canonicalise the path[1] and ninja is reluctant to do so.

Welp.

[1] https://github.com/llvm/llvm-project/pull/117458#issuecomment-2568804774

I investigated this a bit more because even if cmake is getting it wrong, it seems to be caused by the dependency file which is not being consumed by cmake but by ninja (or make).

It is ninja, actually.

https://github.com/ninja-build/ninja/issues/2528

In cmake's defence, the redhat tree layout is not making things any easier.

But still, it is 2025, maybe we should have decent "realpath" implementations in our build systems.

Why is ninja rebuilding my project every time???

Why it says that it has a dependency with a non-existing file called "/opt/rh/gcc-toolset-13/root/include/c++/13/cassert" ???

(I go down a rabbit hole)

Oh I see.

Thanks cmake⸮ 🙃

#professional #cmake

@camelcdr just to confirm I understand the redundant move, we could do the following (to preserve the "tu" semantics) instead, right?

```
bar:
vsetivli zero, 4, e8, m1, tu, ma
vmv1r.v v10, v8
vnsrl.wi v8, v10, 3
ret
```

For pasko I chose to implement sets in two ways (and the runtime picks the best representation at any given moment): a bitfield for values [0..255] (using 4 uint64_t) or a (dynamic) array of sorted integers.

This posed some challenges in how to represent this in the debugger. But I've been able to have gdb show something reasonable, using the power of DWARF expressions.

This is very cool 😃

#pasko #compilers #debugger #gdb

Turbo Pascal vs. Pedro Pascal.

#Pascal

@gafanhoto As melhoras.

@gafanhoto 😂

@gafanhoto 😱😱😱

https://www.instagram.com/reel/DJRwdl-sDx-