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>