`asm goto` was the big one. The x86_64 maintainers broke the clang builds very intentionally just after we had gotten x86_64 building (with necessary patches upstreamed) by requiring compiler support for that GNU C extension. This was right around the time of meltdown+spectre, and the x86_64 maintainers didn't want to support fallbacks for older versions of GCC (and ToT Clang at the time) that lacked `asm goto` support for the initial fixes shipped under duress (embargo). `asm goto` requires plumbing throughout the compiler, and I've learned more about register allocation than I particularly care...
Fixing some UB in the kernel sources, lots of plumbing to the build system (particularly making it more hermetic).
Getting the rest of the LLVM binutils substitutes to work in place of GNU binutils was also challenging. Rewriting a fair amount of 32b ARM assembler to be "unified syntax" in the kernel. Linker bugs are hard to debug. Kernel boot failures are hard to debug (thank god for QEMU+gdb protocol). Lots of people worked on many different parts here, not just me.
Evangelism and convincing upstream kernel developers why clang support was worth anyones while.
Writing the plugin seems to be a hard problem. It’s not clear from the link if there are non trivial plugins written for real formats, not toy not POC but a for reals plugins
All that is true and the spin I focus on is can Microsoft have implemented it such that they have zero (ish) knowledge by default.
We know iCloud has configurations that can’t disclosed, and I wonder if there is a middle ground between if you loose the recovery key you are stuffed and maybe have a recovery key unblocked by a password similar to ssh keys
c++ bootstrapping as a transpiler back when it was a 1 man show is hardly where it’s at today. The point about self handling in ts should demonstrate there is more than just strip the types going on
reply