RFC: compiler options to control what gets built and how

[Marcel Moolenaar]

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 at mac.com