Toolchain: Update LLVM to 18.1.3

[DanShaders]

TODO:

• Wait for spholz to patch the linker script
• Wait for CMake 3.29.2 on Azure: [OpenMP] Missing header omp.h in install directory when building [email protected] with openmp as runtime with [email protected]  llvm/llvm-project#86744, update cmake to >= 3.29.2 actions/runner-images#9680
• Update Toolchain/Patches/llvm/ReadMe.md
• Check LLVM port on GCC build — isn't able to find libstdc++ headers automatically but works

Depends on #23947

CC @spholz @BertalanD @ADKaster

[alimpfard]

wanna explain briefly what to mess with in the cmake files? not a requirement, but this reads like "fuck you, not my problem".

[DanShaders]

It is really just "I don't care how you get your libc, just get it". I think what has to be done is the following:

• compile clang without runtimes
• make llvm not set -Wl,-z,defs for runtime
• make empty libc.so stub
• compile runtime
• compile Serenity
• generate proper libc.so stub
• undo -Wl,-z,defs patch

Or you can cheat and first compile Serenity using GCC toolchain and grab libc from there.

[alimpfard]

(I mostly meant giving a better description in the document than ":shrug: get a libc build")

[alimpfard]

I kinda don't like that we're committing object files into the repo.

[DanShaders]

Introducing backdoor payload in stub libraries that are neither linked in nor executed. (Well, theoretically I can execute code in them during CMake configure checks that try to run executables but that would require providing correct interpreter and runtime paths somehow)

More seriously, I think the ideal solution would be to have a LibC stub source that looks like

extern "C" {
void fopen() {}
void fclose() {}
...
}

and then we can compile it with -nostdlib in between two stages of llvm compilation to get an actual stub. At this point, we would probably also want to ensure in CI that it is always up-to-date. But this PR is already too big for what it does so let's just commit binary files.

[alimpfard]

Not really concerned with the security aspect, more so that these lovely files just feel wrong to have.

not too strongly opinionated on it tho, we already have them in master so :yakshrug:

[ADKaster]

Looks good to me. @BertalanD any final thoughts? or @implicitfield ?

[ADKaster]

I found that the Serenity build itself had trouble with these cmake versions. we should ban them in either Serenity/CMakeLists.txt or Meta/serenity.sh in a follow-up.

[BertalanD]

lg2m, and thanks for picking this up

For Ali's comment about the bootstrapping docs, I'd appreciate a link in the docs to the discussion here, but I don't think we need to go into more detail.