Roughly: build against all kernels listed in /lib/modules
E.g:
l /lib/modules
5.3.13-300.fc31.x86_64
5.3.14-300.fc31.x86_64
Right now I have an ordinary KBuild and pass the location of the kernel module with -C looks like the following line.
[..] -C ${KERNELHEADERS_DIR} modules [...]
Is there a way to pass multiple kernel headers into -C of Kbuild?
Related
In my project I have makefiles which build Solaris kernel modules, and they use gcc to compile files but use ld to link all .o files together into a kernel module. I am trying to include some coverage options like gcov (-fprofile-arcs) or tcov (-xprofile=tcov) in my build, hence I want to replace ld with gcc during linking also.
But as soon as I use replace gcc with ld, the builds start failing with lot of "undefined symbol" errors, even if I use some compile flags and get rid of these errors, the kernel module will not load into my Solaris kernel at all.
For example:
$ /usr/ccs/bin/ld -r -dy -Nstrmod/rpcmod -Nfs/nfs \
-Nmisc/rpcsec -Nmisc/klmmod -Nfs/zfs \
-o debug64/nfssrv \
debug64/nfs_server.o debug64/nfs_srv.o debug64/nfs3_srv.o \
debug64/nfs_acl_srv.o debug64/nfs_auth.o obj64/nfs41_srv.o \
obj64/ctl_ds_srv.o obj64/dserv_server.o
ld works fine but with gcc I get following errors:
/opt/gcc-4.4.4/bin/gcc -m64 -z muldefs \
-Lmod/rpcmod -Lfs/nfs -Lmisc/rpcsec \
-Lmisc/klmmod -Lfs/zfs \
-o obj64/nfssrv \
obj64/nfs_server.o obj64/nfs_srv.o obj64/nfs3_srv.o
obj64/nfs_acl_srv.o obj64/nfs_auth.o obj64/nfs41_srv.o
obj64/ctl_ds_srv.o obj64/dserv_server.o
Undefined first referenced
symbol in file
hz obj64/nfs_server.o
p0 obj64/nfs_server.o
nfs_range_set obj64/nfs41_srv.o
getf obj64/nfs_server.o
log2 obj64/nfs4_state.o
main /usr/lib/amd64/crt1.o
stoi obj64/ctl_ds_srv.o
dmu_object_alloc obj64/dserv_server.o
nvpair_name obj64/nfs4_srv.o
__dtrace_probe_nfss41__i__destroy_encap_session obj64/nfs41_srv.o
__dtrace_probe_nfssrv__i__dscp_freeing_device_entries obj64/ctl_ds_srv.o
mod_install obj64/nfs_server.o
xdr_faststatfs obj64/nfs_server.o
xdr_WRITE3res obj64/nfs_server.o
svc_pool_control obj64/nfs_server.o
Warning the option -L allows to specify a path where to search for libraries, to specify a library you want to link with you (also) have to use the option -l
So a priori you have to add the options -lrpcmod -lnfs -lrpcsec -lklmmod -lzfs
More details in GCC Linking Options
By default, the GNU linker called through the gcc compiler driver will try to create a standard executable. Consequently, if you don't tell it otherwise, ld will use its default linker script, the C startup code and it will look for a main() routine and everything else that makes a valid executable.
I'm not too familiar with Solaris, but would bet this will not be suitable to build kernel modules. I would expect kernel modules will at least require some options like -ffreestanding, -nostdlibs and most likely a non-default linker script that's probably very different from the default one used for applications.
Even if you manage to link your kernel modules this way, I seriously doubt you will be finished. The gcov instrumentation routines most likely do not expect to live within a kernel driver but expect a proper C execution environment (e.g. it will at least expect to fopen() a file to fwrite() its findings). A kernel driver, however, does not have this comfort. You'll probably find yourself confronted with the problem to get the gcov data somehow out of your kernel modules.
Not saying this is not doable, but it certainly will be a lot of work.
U-boot being a bootloader targeted at different architecture and SoC's, there are several source files, and only some of them makes it to the final executable for a particular board. For example, in the arch/ directory, there is one directory per architecture. If the build is for an ARM architecture SoC, only some of the files in arch/arm/ will be compiled into the executable.
Which of the source files get compiled into the executable depends on the configuration of the build. This configuration is controlled by a file present in configs/ directory. In case of BeagleBone Black, this file is configs/am335x_boneblack_defconfig. This file defines several variables, which are used in Makefiles.
A part of the configs/am335x_defconfig is shown below:
CONFIG_ARM=y
CONFIG_ARCH_OMAP2PLUS=y
CONFIG_TI_COMMON_CMD_OPTIONS=y
CONFIG_AM33XX=y
CONFIG_DISTRO_DEFAULTS=y
The variables defined in these files are later referenced in other Makefiles. For example, the CONFIG_AM33XX variable defined above is referenced in /arch/arm/mach-omap2/am33xx/Makefile as shown below:
obj-$(CONFIG_AM33XX) += clock_am33xx.o
obj-$(CONFIG_TI814X) += clock_ti814x.o
obj-$(CONFIG_AM43XX) += clock_am43xx.o
ifneq ($(CONFIG_AM43XX)$(CONFIG_AM33XX),)
obj-y += clock.o
endif
I guess while executing the command
$make am335x_boneblack_defconfig
the value of the variable CONFIG_AM33XX gets replaced in some transient copy of the Makefile, so that the content of the above makefile gets replaced by
obj-y += clock_am33xx.o
Figuring out which source files are included in the final executable just by searching for the config variables in all the Makefiles is a tedious task.
I need a way to create a list of source files which gets compiled for a particular config file automatically. Is there a way to do it?
Just do a clean build and search for all object files:
make mrproper
make foo_defconfig
make -j6
find . -name '*.o'
You probably want to exclude directories tools/ and scripts/.
I am a newbie in Kernel Development. I was trying to understand the following makefile for Hello World! program. But I am not able to figure it out completely.
obj-m += hello.o
all:
sudo make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
sudo make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
I am not able to understand what is meant by 'obj-m += hello.o' . I know m here means module and thats it.
Also why are we not defining the dependencies of hello.o
And lastly I am not able to figure out completely the compiling rules defined under all: and clean:
Any help would be highly appreciated.!!
obj-m is a Makefile variable. It actually consists of 2 parts: 'obj' means that the referred target is a kernel object, while 'm' part means that the object is to be build like a module.
The variable is considered by kernel build rules. As kernel modules follow a certain convention, running your Makefile will result in creation of module hello.ko from source file hello.c (if everything works properly).
The 'obj' variable may take different suffixes as well. For example 'obj-y' will try to link the referred object into the main kernel image, instead of creating a module. The suffix may also refer to a kernel .config file variable, like this:
obj-$(CONFIG_HOTPLUG) += hotplug.o
In this case, if CONFIG_HOTPLUG is set to 'y' the hoplug object will be compiled into the main kernel; if set to 'm' then a separate hotplug.ko loadable module will be created. If not set to anything (resulting in 'obj-'), hotplug will be omitted outright.
I am building a set of Linux kernel modules using shared source code. From what I understand, the Makefile has to be named "Makefile" so I have to use the same Makefile to build two different modules. How can I build two different modules, within the same Makefile, with the same source code, but with two different build options?
For example, my modules are called module1 and module2. So I have the following line to define them:
obj-m := module1.o module2.o
Among other files, both module1 and module2 need to use the same source file code.c, but built with different build options. So say for example, the Makefile contains the following lines:
module1-objs = module1_code.o other_code.o
module2-objs = module2_code.o other_code.o
I want module1_code.o and module2_code.o to be built from code.c, but with different options. Specifically, I want one module1_code.o with a macro defined -DPREPROCEFFOR_FLAG=1, and module2_code.o built without the macro.
From what I understand, the system of Makefiles used in Linux implicitly infers that for an object file called "code.o", the source file is called "code.c", so how would I achieve this? Is is possible? Is there a better way to do this?
You have a problem here, because you obviously have code.c being compiled differently when -DPREPROCEFFOR_FLAG=1 is defined, but once it's compiled into code.o, make won't care about preprocessor flags or whatever because code.o will be already up to date.
You need a way to build code.c to different object files with different C flags. There's probably a clean way to do this (had no chance with O= for out of tree modules), but here's my innelegant yet effective solution for the moment:
my_modules:
cp code.c code_noflags.c
cp code.c code_withflags.c
make -C $$KDIR M=$$PWD modules
rm code_noflags.c code_withflags.c
# module objects
obj-m := module1.o module2.o
# module1 specifics
module1-y := code_withflags.o
CFLAGS_code_withflags.o := -DPREPROCEFFOR_FLAG=1
# module2 specifics
module2-y := code_noflags.o
Just call:
$ make KDIR=/path/to/kernel
You can verify the preprocessor flag is passed to the source file for the right object with:
$ make KDIR=/path/to/kernel V=1 | grep PREPRO
You could also have two separate directories for each module, if this is possible, and have a symbolic link code.c in each one pointing to the common real code.c. However, this is still hackish and doesn't feel right.
One simple solution is, continuing from your Makefile
obj-m := module1.o module2.o
module1-objs = module1_code.o other_code.o
module2-objs = module2_code.o other_code.o
to add two more source files, module1_code.c and module2_code.c.
Then module1_code.c just looks like:
#define PREPROCEFFOR_FLAG 1
#include "code.c"
and module2_code.c is:
#include "code.c"
Or if you like, change the names in the Makefile and source files so that the second include without a define isn't necessary. Also you could make the two source files nothing but an include and use the CFLAGS_module1_code.o variable to add the -D... option to the compiler if you prefer.
This is similar to what happens in the upstream kernel with arch/x86/boot/video-vesa.c and arch/x86/realmode/rm/video-vesa.c etc., where the realmode file just contains:
#include "../../boot/video-vesa.c"
and the video-vesa.c code ends up getting compiled twice with different compiler flags.
This seems preferable to copying the source files, since you end up with a mess there if you want to use the O=... option to the kernel build to keep a clean source tree and build in a separate object tree.
I have a Make-based project where the top-level target requires multiple vmlinux binaries (linux kernels) as pre-requisites, so it looks something like:
all: bigfile
bigfile: bigfile.cfg a/vmlinux b/vmlinux c/vmlinux foo bar baz
sometool -obigfile -ibigfile.cfg # other inputs referenced from within the config
and each linux rule looks more or less like:
a/vmlinux: a/.config
$(MAKE) -C $(A_LINUX_SRC) O=$(PWD)/a vmlinux
a/.config
mkdir -p a
$(MAKE) -C $(A_LINUX_SRC) O=$(PWD)/a $(A_LINUX_DEFCONFIG)
Similarly for b and c linux kernels. Note each may have the same or different source trees, and almost certainly will have different defconfigs.
This works for clean builds but I don't really like the recursive call to make. Depending on how I tweak the above few lines, I seem to end up with either one of:
unnecessary recursive makes into linux trees even when nothing changes (which takes 7 seconds to do nothing)
if I edit linux sources, kernel's aren't re-generated unless I explicitly touch the .config or something.
Ideally, I'd like my top level Makefile to be aware of the interior dependancy graph of each linux kernel and "do the right thing" under all circumstances. (i.e the recursive-make-considered-harmful argument).
Although I expect the top-level Linux Makefile won't be happy to be included by some one else, especially multiple times with different configs and src trees!
(I have control over baz/makefile.inc bar/makefile.inc so they can be written to play nice when included by the top level)
Or am I out of luck, and will just have to remember to touch .configs to trigger a decent into each linux build dir?
Thanks,
Dave
EDIT:
the 7-second useless decent into a linux tree looks like this on my mahchine:
$ time make
make -C /home/davidm/md/tests/linux O=/home/davidm/md/tests/linux_a vmlinux
make[1]: Entering directory `/home/davidm/linux-2.6.38'
Using /home/davidm/linux-2.6.38 as source for kernel
GEN /home/davidm/md/tests/linux_a/Makefile
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[3]: `include/generated/mach-types.h' is up to date.
CALL /home/davidm/md/linux-2.6.38/scripts/checksyscalls.sh
CHK include/generated/compile.h
make[1]: Leaving directory `/home/davidm/md/linux-2.6.38'
real 0m6.577s
user 0m2.930s
sys 0m1.360s
In order for this to work correctly, you really do have to recurse into the kernel source directories on every build. 7 seconds really isn't that bad for checking whether any file in the massive kernel tree has changed...
Including the kernel makefile in your build somehow wouldn't actually help, because the kernel build itself uses recursive make.
Perhaps something like this:
a/.config
mkdir -p a
$(MAKE) -C $(A_LINUX_SRC) O=$(PWD)/a $(A_LINUX_DEFCONFIG)
.PHONY: kernel-a-build
kernel-a-build: a/.config
$(MAKE) -C $(A_LINUX_SRC) O=$(PWD)/a vmlinux
bigfile: kernel-a-build
Since kernel-a-build is a "phony" target (it doesn't correspond to a physical file), it will be run on every single build, allowing the kernel makefile to notice changes to the source files.