RFC: compiler options to control what gets built and how

[Adrian Chadd]

.. kernel modules generally need opt_xxx.h in order to correctly build
with things like debug flags.

net80211 for example changes the calling ABI depending upon whether
IEEE80211_DEBUG is enabled or not.



-adrian


On 20 November 2013 09:08, Marcel Moolenaar <xcllnt at mac.com> wrote:
> 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
>
>
>
> _______________________________________________
> freebsd-ppc at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"