I am writing a simple device driver in Linux. In the makefile we normally write first line as
obj-m += hello.o
where hello is the module written. I have seen in other makefiles the symbol += being replaced by := and some others. What is significant difference between the two and also what are the possible options?
Actually, Kbuild resets obj-m along with some other variables (see scripts/Makefile.build) before including user Makefile, so there is no difference between += and := assignments (assuming that there is the only hello.o line).
Personally I would prefer appending assignment (+=). This prevents some stupid errors like the following:
obj-m := hello.o
obj-m := world.o
If the last line is a copy-paste of the first one and you forget to change the assignment type to +=, then you'll get only world.o compiled (without hello.o).
I would also suggest you to read Kbuild documentation about how to write module makefiles.
Related
For a lpc3250 board, we had to developer a Linux kernel module to control the PWM output. I've created a 'helper' module which contains methodes like PMW1_ENABLE which set the correct bit at 1.
Unfortunately I run into problems when I create multiple .c and .h files. When I put all the code in just 1 file, the solution works fine. When I split it nicely in additional .c and .h files, something weird is happening. Even just printk statements do not show up on the console.
Most weird part, during cross compiling, no errors are shown so it looks like the binary is ok but it isn't.
Does this sound familiair? Could it be an issue with my makefile?
ARCH := arm
CROSS_COMPILE := /usr/local/xtools/arm-unknown-linux-uclibcgnueabi/bin/arm-linux-
CC= $(CROSS_COMPILE)gcc
obj-m := pwmdriver.o
pwmdriver-objs := pwmhelper.o pwmdriver.o
KDIR := /home/student/felabs/sysdev/tinysystem/linux-2.6.34
WORKINGDIRFIXED := /home/student/PRT/5_AssigPWM
export
all:
$(MAKE) -C $(KDIR) M=$(WORKINGDIRFIXED) modules
clean:
$(MAKE) -C $(KDIR) M=$(WORKINGDIRFIXED) clean
In the kernel module makefile obj-m variable exists. Consider the following:
CUR = $(shell uname -r)
DIR = /lib/modules/$(CUR)/build
PWD = $(shell pwd)
obj-m := m1.o m2.o
default:
$(MAKE) -C $(DIR) SUBDIRS=$(PWD) modules
In this Makefile, the default target contains a recipe which invokes kernel sub-make. The obj-m variable doesn't get exported to environment thus sub-make cannot use it. But if we delete the obj-m variable initialization, then this make doesn't compile m1 and m2 kernel modules. So, question is:
Why kernel sub-make depends on the non-exported obj-m variable in this case?
None of the make variables are exported to the environment.
SUBDIRS gets defined as a make variable.
The kernel makefile looks for the Makefile in SUBDIRS, reads it, and uses any obj-* defined therein.
(According to the documentation, you should use M instead of SUBDIRS.)
I would like to compile a simple character device module depending on a custom header. The folder is thus organized,
+ mymod.c
| customized-header.h
| customized-header.c
| Makefile
In mymod.c, the header is thus used,
#include "customized-header.h"
In Makefile:
obj-m := mymod.o
mymod-objs := customized-header.o
KVERSION = $(shell uname -r)
PWD = $(shell pwd)
all:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) clean
Everything should work fine, the module gets compiled without problem, I can load the module through sudo insmod, but the module doesn't work properly. When I checked nm mymod.ko, there are a lot of vars and functions are missing. It looks as if it stopped after linking customized_header.o. If I remove this header and its function, say no header function calls from the module, it compiles perfectly with desired result.
Could you see what went wrong here?
The problem resides in the Makefile. Due to the link here, I changed it into
obj-m: mymodko.o
mymodko-obj: customized-header.o mymod.o
It now works fine. So the question was the naming of module object. We need to specify different names as in this case mymodko.o and mymod.o.
I am pretty familiar with Makefiles and kernel modules, but recently I got a problem in my Makefile that doesn't make any sense -- on using wildcards.
To demonstrate this, I am compiling a hello world kernel module from scratch.
The directory structure is like this:
hello_mod/
|
--- hello.c
|
--- Makefile
Here is the actual makefile :
CFILES := $(wildcard hello.c*)
#CFILES := hello.c
OBJS := $(CFILES:.c=.o)
KSRC := /lib/modules/$(shell uname -r)/build
obj-m += hello_world.o
hello_world-y := $(OBJS)
all:
#echo $(CFILES)
$(MAKE) -C $(KSRC) M=$$PWD modules
clean:
$(MAKE) -C $(KSRC) M=$$PWD clean
.PHONY: clean
The problem is that even though the commented $(CFILES) and the uncommented $(CFILES) are exactly the same, the build fails on using the first $(CFILES) with the following error:
*** No rule to make target `/home/test/hello_mod/hello_world.c', needed by
/home/test/hello_mod/hello_world.o'. Stop.
If the commented $(CFILES) is used, it works perfectly.
If someone wants to test this out, I'm including the source for the hello world source which is hello.c :
#include <linux/kernel.h>
#include <linux/module.h>
static int mod_init()
{
printk("Hello\n");
return 0;
}
static void mod_exit()
{
printk("Bye world\n");
}
module_init(mod_init);
module_exit(mod_exit);
Does anyone know why it is behaving as such? And I need to use wildcards in the makefile. Any help will be appreciated.
There are two makes happening here. The first really only relies on the KSRC variable and the recursive make call. The second make only needs the CFILES, OBJS, obj-m, and hello_world-y variables, and doesn't make use of the all: target. So your debug is showing that CFILES is set correctly for the first Make, where it's not being used, and is not showing it in the second make, where it is.
You're wildcard expanding from a different directory, and not picking up the right files. Try this for CFILES:
CFILES := $(notdir $(wildcard $M/hello.c*))
SRCDIRS := subdir1 subdir2
CFILES := $(strip $(foreach dir,$(SRCDIRS),$(wildcard $(dir)/*.c)))
should probably be (see foreach example in documentation)
SRCDIRS := subdir1 subdir2
CFILES := $(foreach dir,$(SRCDIRS),$(wildcard $(dir)/*.c))
(no need to $(strip), .... or perhaps
CFILES := $(wildcard {subdir1,subdir2}/*.c)
Use remake, probably as remake -x, to debug such issues.
I'm working on a Linux kernel module for a 2.6.x kernel and I need to view the assembly output, though it's currently being done as a temporary file an deleted afterwords. I'd like to have the assembly output mixed with my C source file so I can easily trace where my problem lies. This is for an ARMv6 core and apparently objdump doesn't support this architecture. I've included my makefile below.
ETREP=/xxSourceTreexx/
GNU_BIN=$(ETREP)/arm-none-linux-gnueabi/bin
CROSS_COMPILE := $(GNU_BIN)/arm-none-linux-gnueabi-
ARCH := arm
KDIR=$(ETREP)/linux-2.6.31/
MAKE= CROSS_COMPILE=$(CROSS_COMPILE) ARCH=$(ARCH) make
obj-m += xxfile1xx.o
all:
$(MAKE) -C $(KDIR) M=$(PWD) modules
clean:
$(MAKE) -C $(KDIR) M=$(PWD) clean
Objdump does support that architecture. Your executable will be called arm-none-linux-gnueabi-objdump
Assuming gcc and the gnu assembler a more readable output than objdump can be had. Tell the assembler to retain its intermediate code using flags to gcc:
-Wa,-alh=basename.s
And to get basename to be the actual source filename you need to tell make:
-Wa,-alh=$<.s
which will leave piles of foo.c.s files laying around your source directory. The big problem here is that the way gcc works it uses temporary files between code generation and assembly. I can't find a way to make gcc save its intermediates but the assembler is happy to stash a listing for you.
Getting that argument into the Makefile CFLAGS is left as an exercise for the reader (because I kinda hate "make" and hate "gnu info" even more.
To get an assembly language listing of my Linux kernel modules, I added the assembler switches to the kernel scripts/Makefile.build.
#cmd_cc_o_c = $(CC) $(c_flags) -c -o $(#D)/.tmp_$(#F) $<
cmd_cc_o_c = $(CC) $(c_flags) -c -Wa,-alh=$<.lst -o $(#D)/.tmp_$(#F) $<
You could try the flag "-save-temps" to gcc.
It works for me in my embedded project, I haven't tried it on kernel builds.
The proper way is likely to add target dependencies in your module makefile / Kbuild file:
always-m += basename.s
(As kbuild has the proper targets to generate the .s files)
If you are lazy as I am, this could look like:
MOD_NAME := some_module_name
myunits := file1 file2 file3 ... and many more... without .c extension
obj-m := $(MOD_NAME).o
$(MOD_NAME)-y := $(addsuffix .o,$(myunits))
# Comment/uncomment to generate assembly / preprocessor output
always-m += $(addsuffix .s,$(myunits)) $(MOD_NAME).mod.s
always-m += $(addsuffix .i,$(myunits)) $(MOD_NAME).mod.i
(2 bonuses here: assembly for the generated module meta-registration file, and the preprocessor output)