Date: Wed, 20 Nov 2013 09:08:36 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: powerpc@freebsd.org Cc: Warner Losh <imp@bsdimp.com> Subject: RFC: compiler options to control what gets built and how Message-ID: <3D481595-1F61-4244-838F-5C13ABCB830D@mac.com>
next in thread | raw e-mail | index | archive | help
All,
Background:
Juniper is refocussing efforts towards PowerPC again. Primarily
what this means for Juniper is that a select set of PowerPC-
based Juniper products will migrate to the latest FreeBSD as
the base OS underneath Junos.
What this means for FreeBSD is that Juniper will be contributing
a bunch of goodies :-)
Problem at hand:
Juniper builds kernel modules without any reference to a kernel
configuration. This works great for architectures like x86, but
for PowerPC, MIPS and ARM this isn't always that easy. The problem
as far as I can see it is that we use kernel configurations to
indicate for which CPU we're compiling. Let's call this the
build setting for arguments sake.
Complication:
Many embedded CPU architectures have specific compiler behaviour
you may have to tell the compiler for what CPU or ABI you're
compiling. Let's call this the compiler setting. Having both a
build setting and a compiler setting is, well, complicating.
What I'd like to change is that we use compiler settings more
than build settings, for where it's applicable of course and as
a first stab, do it for PowerPC only. If it's successful then
it should be fairly easy to apply to ARM and MIPS.
Examples:
1. A compiler that generates 64-bit code can be assumed to
compiler a 64-bit PowerPC kernel. There is no need to have
a build option (like machine powerpc powerpc). Testing for
__LP64__ or something like that will do just fine.
2. The difference between AIM and Book-E is (can) be handled
by checking the appropriate compiler defines (__embedded__)
and have us do the right thing in the kernel for modules
and for user space.
Particular use case:
1. Cross-tools aren't necessarily helped by the magical and
automatic selection of appropriate definitions. This is not
a problem that is in search of a solution though. Our ELF
headers handle this adequately and the same scheme can work
for things like trap frames and the likes.
2. The remote kernel debugger stub needs different register
definitions for Book-E and AIM. These register definitions
are controller by the compiler options used, yet our stub
uses build settings. This has previously resulted in an
inability to debug the kernel remotely due to a mismatch.
3. The buildbot I setup at Juniper builds a LINT kernel for
each CPU architecture. For PowerPC this adds an avoidable
complication that we actually need to use a different LINT
kernel configuration for no other reach than that we need
"machine powerpc powerpc64"
rather than
"machine powerpc powerpc"
A distinction that is almost entirely unnecessary.
What needs to change to make this work:
1. Since config(8) is the tool we use to pick up source files,
and we use the abovementioned build options to select the
right source files, we need a way to inject compiler defines
into the process of configuring the kernel build.
2. We need well-defined built-in compiler defines for building
AIM vs. Book-E and 32-bit vs 64-bit.
What do people think of using the compiler to drive more of what
and how we built so that the right thing happens with fewer
manual setup?
--
Marcel Moolenaar
xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D481595-1F61-4244-838F-5C13ABCB830D>