Compiler toolchain roadmap

[Warner Losh]

On Apr 6, 2014, at 1:06 PM, Adrian Chadd <adrian at FreeBSD.org> wrote:
> They may want to bring up an operating system (eg android) on a new
> CPU family without having to wait for the upstream compiler to have
> support. So they'll jump through hoops to make sure they can use their
> internal compiler fork and then merge stuff back into upstream LLVM
> when things have shaken out.

We have basic out-of-tree toolchain support today (though it is a bit clang centric due to esoteric differences in things like -B). I’ve been working in the background to improve this support, as well as bring FreeBSD gcc changes forward to newer gcc’s (at least the ones that make sense to me: all the !x86 mods, the format changes, the platform support). This will be critical if we’re going to support, say, cross building sparc64 from a ports-based compiler from scratch (which we have extremely limited/poor support for today due to bootstrapping issues).

I know there’s also a big desire on some fronts to go all in on gcc 4.9 or some other gplv3 compiler where the ARM or MIPS or <weird-architecture-next> is so much better than the ancient 4.2.1 we have in the tree. So it isn’t even just the experimental bleeding edge R&D lab folks that need to do this.

Plus we have a boatload of issues with just doing a buildworld and/or buildkernel with, say, gcc49… And our build infrastructure needs to grow better version support for gcc and clang (right now you get one version, which makes for some rockiness if you are building current in some scenarios on 9.2 where clang versions differ).

That’s much to be done, and not a lot of doing. I’m likely forgetting other areas we need to focus on as well...

> I'm definitely not arguing "make everything work for old MIPS and ARM
> platforms". I'm totally on board with the "C99 and then C11 should
> just be required at this point." But part of the point of supporting
> external compiler stuff isn't just to make MIPS, ARM and PPC stuff
> work. It's to keep us honest. We as a project treat non-x86 as a
> second class citizen and it shows in our build infrastructure (ie,
> everything is native.) It's similar to the 32 vs 64 bit platform stuff
> - it again made the codebase better, even if it was "ew, DEC alpha.”

You can do arm and mips native builds, it is just that the machines that you have available are significantly under resourced compared to x86 servers. I mean, you aren’t going to find any ARM or MIPS machines that can do a build world in 12 minutes…

> As an example here - I get the feeling that people care not about
> 32-bit x86 and would like it to die. The lack of interest and use of
> freebsd/i386 by developers sometimes shows - suddenly KVA isn't
> infinite anymore and a lot more stuff assumes large amounts of
> physical RAM. But besides the recent push by Intel for all of their
> x86 32-bit embedded stuff (which is all Linux, by the way), those
> decisions also impact the 32 bit ARM platforms. Those aren't going
> away.

There’s two issues here. One is people assuming KVA is cheap and other things like this. The second is bodies to help (a) educate and (b) implement for the smaller platforms. Over the years we’ve grown up a fair amount of embedded platform support. Now the time is ripe to push to the next level of support: where the server guys talk to the embedded guys and vice versa on a more regular basis. I see this happening a bit already, and would encourage more of it.

Warner