RFC: Revitalization of the x86_gcc2 ecosystem

[PulkoMandy]

@trungnt2910

Right - so essentially you agree to adopt Clang if it magically supports the GCC2 ABI, and reject the rest of the RFC (the part that involves migration to GCC2 ABI), am I correct?

Maybe it’s a good idea to start with that. Let’s see if we can get clang to replace gcc2 as a first step without touching anything else (or as little as possible). I think you already showed that this looks possible at least for a demonstration (I expect some more problems will show up if we try to run every BeOS app with a system entirely built this way?).

Once we have that part, we can decide if depreacting the itanium ABI for x86 32bit is desirable (cornering us into a non-standard ABI instead of what pretty much everyone else uses), or if the two ABIs can live side by side in a way that is easier to handle than the current option (which is: library path hacks and extra complexity in haikuporter recipes).

We will also at that point see if the current option is also useful in other cases: 32/64 bit hybrids, maybe R1/R2 hybrids when there is an ABI break someday, … this ends up touching a lot more topics than “let’s just get rid of gcc2”.

@trungnt2910

Without a setarch-style tool, how would you ensure a BeOS binary gets the ABI it needs when it requests libroot.so on a GCC4 primary environment?

This isn’t correct, you can start a BeOS binary inside of a setarch environment and it will work just fine (or a gcc4 binary outside a setarch environment). The runtime_loader detects the ABI from a few fields in the ELF header and sets up the library search path for the executable accordingly.

setarch only changes the PATH environment variable so that when you run “gcc” it runs gcc from /bin/x86 instead of /bin/. Everything else is handled by having a different set of compiler tools (for example, a different version of pkg-config that will look for the “right” .pc files for the architecture). There isn’t so much a hack here, just adding your toolchain to the PATH wrapped in a convenient tool.

@jackburton

For example, we cannot build a recent ICU version on gcc2, and we need to build DIFFERENT versions of ICU on gcc2 and gcc > 2 systems. Since we implement our public API on top of ICU, in certain cases we can’t expose the same API on gcc2 and > gcc2 systems.

But that is already solved in the case of just replacing gcc2 with clang and otherwise keeping an hybrid setup, I think?

[trungnt2910]

@nephele

Kinda. The “original” idea was to use clang for the gcc2 abi, and compile the _gcc2 variant of the userland with it.

Thank you. That is all I need to demonstrate to the LLVM developers. We may disagree on how this toolchain may be used, but right now I need to prove that this will be used and get the word from enough members from the Haiku community.

@PulkoMandy

There isn’t so much a hack here, just adding your toolchain to the PATH wrapped in a convenient tool.

Interesting, maybe I am mistaken here. I thought it also sets LIBRARY_PATH, since I have gotten into cases where runtime_loader prints errors for a command and works correctly if I setarch before running the same thing.

@PulkoMandy

But that is already solved in the case of just replacing gcc2 with clang and otherwise keeping an hybrid setup, I think?

Yes, this is essentially my adoption plan but with the final migration steps removed and keeping the hybrid setup. We compile modern libraries with the new toolchain but primarily to trim build dependencies.

@nephele

If you call ::Draw for example this will just use the ::Draw() in the gcc2 abi, and the implementation would call the ::Draw() from the Itanium abi, but with any BeOS specific nuanced dealt with beforehand.

Yes, but for many libbe APIs, you also need an object to call it on, right? And what if user-provided callbacks throw exceptions across ABI boundaries?

Handling this itself is a big hack.

[cocobean]

clang for the gcc2 abi, and compile the _gcc2 variant of the userland with it.

This seems like such a great idea…

[nephele]

I don’t think exceptions were a thing in BeOS? I would suppose the layer would handel them