svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib

Warner Losh imp at
Fri Apr 4 16:24:18 UTC 2014

On Apr 4, 2014, at 7:44 AM, Jordan Hubbard <jkh at> wrote:

>> For embedded uses, we'd also like to build FreeBSD with vendor's-ugly-hacked-up-gcc-of-the-week.  This is less of an issue now for ARM, but MIPS vendors still hack up gcc in such a way that there's no way that they can get their changes upstreamed and then ship the result with their chips.
> I see.  That’s pretty ugly indeed - is there a list of FreeBSD MIPS folks doing this somewhere?  I ask out of curiosity to know if there’s any collective attempt to chain them all together and insist that they improve clang/MIPS to the point where they can stop doing ugly-ass gcc ports. :)

Good luck with that. There are some vendors that have good engagement with FreeBSD and the community. There are others where the engagement is sporadic at best. FreeBSD is a second tier item, and gcc works well enough for Linux, so what’s your problem? Also, it is more culturally acceptable in Linux land to get your compiler from a vendor supplied SDK. There’s some motion to bring that support back to the original (though the horrible term “upstreaming”), but that lags significantly, and often results in a compiler that’s not quite as optimal as the vendor hacked ones, so those tend to live on and on.

ARM has been good about making sure there’s good, clean support for their designs in gcc and clang. MIPS has been adrift for a while, so hasn’t been a driving force in that area (although to their credit, some funding has happened). There are more MIPS variations out there that have been evolving for a long time than with ARM, since most ARM SoC vendors get the core from ARM and do little to nothing with the base core, instead innovating on the peripherals.

The long and the short of this means that we’ll need external toolchain support for FreeBSD, and not only external toolchain support, but better compiler support in the base than we have. Right now we have clang and gcc. At a minimum, we’ll need to grow a version notion (as switches differ), and may need different levels of external toolchain support: just build the system with a pre-built (by magic!) toolchain with sysroot, same without sysroot and the ability to bootstrap the external toolchain...


More information about the svn-src-head mailing list