Toolchain: Upstreaming tracking for gcc/binutils/llvm

[ADKaster]

In order to be a fully accepted CMake target, we should have compiler support upstreamed to at least gcc or llvm-project.

Here's the list of things that need done for that do have a chance of succeeding:

This issue is being tracked at the same time on CMake's GitLab here

In SerenityOS/serenity:

Loader/Kernel/LibELF:

• [ ] (Optional) Support tls-model other than initial-exec: Will remove a patch from each llvm and gcc
  • https://www.akkadia.org/drepper/tls.pdf

LibC:

• [x] Make<ctype.h> POSIX and C standard compliant. Remove hax from libc++ and libstdc++ patches pretending to be newlib. (https://github.com/SerenityOS/serenity/pull/14401)
• [x] (Optional) Unify libdl, libpthread, libc and libm into a mega-library to avoid cyclic dependencies in libstdc++ (#14453)
• [x] scanf improperly reads some integer types on x86_64 (https://github.com/SerenityOS/serenity/pull/14189)
• [x] Remove _aligned_alloc and _aligned_free

---

GNU Autotools:

• [x] config.sub
• [x] config.guess
• [ ] libtool.m4

Binutils:

• [x] Possibly find a way to remove the changed default base address of non-PIE executables? Ask on binutils mailing list if the patch is reasonable (https://github.com/SerenityOS/serenity/pull/14189)
• [ ] Upstream the patch

GCC/libstdc++:

• [x] Split patch up (https://github.com/SerenityOS/serenity/commit/d0edf2627c3d72fa1d59ba173bac1c0cc3cb27e9)
• [ ] Upstream patches

---

LLVM:

• [x] Remove _aligned_alloc patches from libc++ (https://github.com/SerenityOS/serenity/pull/14401)
• [x] Remove patches from libc++ in <initializer_list> (https://github.com/SerenityOS/serenity/pull/14401)
• [ ] Upstream patches

LLVM Lit tests:

• [x] Posix Named Semaphores for python3 multiprocessing.Pool (https://github.com/SerenityOS/serenity/pull/14578)

[ghost]

In order for <ctype.h.> to be POSIX compliant, doesn't <locale.h> have to also be POSIX compliant?

[ADKaster]

I believe our locale.h is compliant -- the C library only accepts the C locale.

The issue with ctype relates to us pretending to be newlib but not having the elements in the _ctype_ global array arranged properly. LLVM chokes on it and we have to tell it to provide its own ctype.h

[ADKaster]

Turns out plenty of systems tell libc++ to provide its own "Rune table" ... so us doing so as well isn't that big a deal.

[ADKaster]

We should update the CMake patches to reflect the fact that LibDL is now an ld-script stub like Musl's by removing the LibDL lib variable from the Platform files.

[timschumi]

LibDL is now an ld-script

Not sure if this is a typo, but better safe than sorry. Both LibDl and LibM are completely normal libraries at the moment, the only library that has been merged into LibC so far is LibPthread.

That said, I do plan to do the same with LibDl and LibM some time in the near future.

[ADKaster]

I created an RFC for LLVM upstreaming here: https://discourse.llvm.org/t/rfc-add-support-for-serenityos/71641