"make all" in usr/src/uts

I've started work to fix a problem with Install, which is a script that kernel developers can use to help install test kernels. So I needed to build a kernel for testing, but I didn't need to build anything outside the kernel. I thought I'd just set up an environment using bldenv], then build using dmake, i.e.,

$ bldenv -d my-env.sh
...
$ cd $SRC/uts
$ dmake all

Notice I used "dmake all", not "dmake install". This is because Install extracts kernel modules from the source tree, not the proto area.

When my build finished, I noticed that there were build errors.

/builds/kupfer/6952783/usr/src/uts/sun4u/serengeti/unix
/usr/ccs/bin/ld -o ../cheetah/debug64/libcpu.so -G -znoreloc -h 'cpu/$CPU' debug64/cpu_module.o debug64/mach_cpu_module.o
ld: fatal: file ../cheetah/debug64/libcpu.so: open failed: No such file or directory
\*\*\* Error code 1
dmake: Fatal error: Command failed for target `../cheetah/debug64/libcpu.so'
Current working directory /builds/kupfer/6952783/usr/src/uts/sun4u/serengeti/unix
\*\*\* Error code 1
The following command caused the error:
BUILD_TYPE=DBG64 VERSION='6952783:66c93397e15b' dmake  symcheck.targ
dmake: Fatal error: Command failed for target `symcheck.debug64'
Current working directory /builds/kupfer/6952783/usr/src/uts/sun4u/serengeti/unix
\*\*\* Error code 1
The following command caused the error:
(cd ../../../sun4u/serengeti/unix; pwd; \\
CPU_DIR=../cheetah SYM_MOD=../cheetah/obj64/unix.sym dmake symcheck)
dmake: Fatal error: Command failed for target `obj64/unix.sym'
Current working directory /builds/kupfer/6952783/usr/src/uts/sun4u/serengeti/cheetah
\*\*\* Error code 1
The following command caused the error:
BUILD_TYPE=OBJ64 VERSION='6952783:66c93397e15b' dmake  all.targ
dmake: Fatal error: Command failed for target `all.obj64'
Current working directory /builds/kupfer/6952783/usr/src/uts/sun4u/serengeti/cheetah
\*\*\* Error code 1
The following command caused the error:
cd cheetah; pwd; dmake  all
dmake: Fatal error: Command failed for target `cheetah'
Current working directory /builds/kupfer/6952783/usr/src/uts/sun4u/serengeti
\*\*\* Error code 1
The following command caused the error:
cd serengeti; pwd; THISIMPL=serengeti dmake  all
dmake: Fatal error: Command failed for target `serengeti'
Current working directory /builds/kupfer/6952783/usr/src/uts/sun4u
Waiting for 3 jobs to finish
      

This was odd for a couple reasons.

First, I used bldenv -d, which sets up an environment for building debug kernel modules. Yet the "obj64" directory names indicated that non-debug modules were being built.

Second, the log seemed to indicate that the non-debug build had some sort of dependency on the debug build. That couldn't be right--the nightly script, which most of us use to drive our builds, does the non-debug build before it does the debug build. So any such dependency would break nightly.

Just what was going on here?

Well, the first thing you have to understand is that the kernel makefiles make heavy use of macros to determine what exactly to build. Do you want 32-bit binaries or 64-bit? Debug or non-debug?

After some poking around, I noticed that for the kernel, the "install" target uses DEF_BUILDS, which is going to specify debug or non-debug (one or the other). The "all" target uses ALL_BUILDS, which specifies both debug and non-debug.

So that answers my first question. I was building a non-debug module because I had used "dmake all" instead of "dmake install".

But why was a non-debug build depending on a debug binary?

Some tracing through the makefiles shows that the symcheck target in uts/sun4u/serengeti/unix/Makefile uses the SYM_BUILDS macro, which that makefile sets to $(DEF_BUILDSONLY64) (i.e., just the 64-bit variant of $(DEF_BUILDS)). Because I had used "bldenv -d", SYM_BUILDS was thus set to "debug64", even though it was being invoked for a non-debug module.

What can we conclude from this? Well, if you're building the kernel in a bldenv environment, it's better to use "make install" than "make all", at least on SPARC systems. (It looks like the x86 builds don't use the symcheck target.) It might be possible to restructure the kernel makefiles to avoid this issue, but I don't understand enough of what's going on here to say for sure.

Comments:

Post a Comment:
Comments are closed for this entry.
About

Random information that I hope will be interesting to Oracle's technical community. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today