[META] Compiling the Coreboot with clang

[llvmbot]

Bugzilla Link	21691
Version	trunk
OS	Linux
Depends On	#5967 #19292 #20713 #21074 #21882 #21912 #21978 #23611
Reporter	LLVM Bugzilla Contributor

Extended Description

This is a meta-bug, other bugs that prevent building Coreboot with clang will be made to depend on it.

We should keep this bug open, until someone no longer needs local patches to have Coreboot built with clang :)

[llvmbot]

I have a few questions about the scope. What parts of clang are in scope and what new features are important? Does this include assembling protected-mode 16-bit stuff? Does coreboot still have its own C compiler that fits everything in registers, and are they looking for llvm to have such a feature?

[llvmbot]

I have a few questions about the scope. What parts of clang are in scope and
what new features are important? Does this include assembling protected-mode
16-bit stuff? Does coreboot still have its own C compiler that fits
everything in registers, and are they looking for llvm to have such a
feature?

Hi Nick, long time..

Largely clang builds all of coreboot now, much work was needed on our side.

#19292 - is a blocker for us to use the integrated asmbler.
#21912 - completely blocks us building at all, we need this one critically.

Coreboot does have its own compiler called 'romcc' that stops cache-eviction, however it is depreciated since newer chipsets are 'CAR (Cache As RAM) ready' and so has dismissing relevance. That is to say, nothing to be concerned with now.

We have a buildbot setup that currently builds our tree with only the patch in #21912 local. This has been a recently development to get this far and the project is still considered alpha going beta-phase.

Hope this answers your questions?
Kind Regards,
Edward O'Callaghan.

[llvmbot]

Hi Nick,

romcc (that special compiler) still exists, but we don't intend to replace that with clang. At least not at this time - it might be a nice student project actually, but since we'll need to keep romcc around for gcc based building anyway, there's not much need to change anything about that.

So the remaining issues are mostly about compiling 32bit code in a freestanding environment (#21538 touches that) and sometimes doing weird things with the assembler (these days mostly ARM assembler flags - the other issues referred here).

[llvmbot]

mentioned in issue #23611

[llvmbot]

mentioned in issue #5967