objtool check segmentation fault when compiling

[smithedtes]

I'm trying to compile a kernel module per Brad's video series here:

https://forums.ni.com/t5/NI-Linux-Real-Time-Documents/Working-with-the-Linux-Kernel-on-NI-LabVIEW-RT...

I'm doing so on an actual linux PXI target. I've downloaded the linux source and performed the first few steps, although I can't get the entire kernel to compile:

/bin/sh: line 1:  7655 Segmentation fault      ./tools/objtool/objtool check --no-fp --retpoline "init/.tmp_main.o"
make[3]: *** [scripts/Makefile.build:327: init/main.o] Error 139
make[2]: *** [Makefile:1044: init] Error 2
make[1]: *** [scripts/package/Makefile:106: ni-pkg] Error 2
make: *** [Makefile:1371: ni-pkg] Error 2

To skip past it I've tried looking around at other documents which suggest running make oldconfig, make prepare, make modules_prepare, and so on. With the source on the machine, I've tried running Brad's ninoop module makefile and it gets the same error:

   ./tools/objtool/objtool check  --module --no-fp  --retpoline "/home/admin/ninoop-module/.tmp_ninoop.o";
/bin/sh: line 1:  3607 Segmentation fault      ./tools/objtool/objtool check --module --no-fp --retpoline "/home/admin/ninoop-module/.tmp_ninoop.o"
make[2]: *** [scripts/Makefile.build:333: /home/admin/ninoop-module/ninoop.o] Error 139
make[1]: *** [Makefile:1532: _module_/home/admin/ninoop-module] Error 2
make[1]: Leaving directory '/home/admin/linux'
make: *** [Makefile:8: all] Error 2

I've edited my makefile to look like this, where BKMS is set to the directory of my downloaded kernel source

obj-m += ninoop.o

BMKS?=/home/admin/linux/
BMARCH?=x86_64
BMVERBOSE?=1

all:
        make V=$(BMVERBOSE) ARCH=$(BMARCH) -C $(BMKS) M=$(PWD) modules

clean:
        make V=$(BMVERBOSE) ARCH=$(BMARCH) -C $(BMKS) M=$(PWD) clean

I've also tried compiling against /lib/module/4.14....(uname -r)/build

When I go in here I get a different error

make[3]: *** No rule to make target 'arch/x86/entry/syscalls/syscall_32.tbl', needed by 'arch/x86/include/generated/asm/syscalls_32.h'.  Stop.
make[2]: *** [arch/x86/Makefile:257: archheaders] Error 2
make[1]: *** [scripts/package/Makefile:106: ni-pkg] Error 2
make: *** [Makefile:1371: ni-pkg] Error 2

I'm essentially trying to get a basic kernel module to compile so that I can try to compile a vendor's code for nilrt. Because the platform is so unique I figure compiling on the target is best (in fact the vendor's installer does this). So are there some special steps I need to follow to make kernel compilation work on an actual target?

[smithedtes]

Forgot to add, if I run Brad's ni noop makefile against the kernel source on target (downloaded, I think, by opkg, but prior to running make prepare) I get this:

make V=1 ARCH=x86_64 -C /lib/modules/4.14.87-rt49-cg-7.0.0f0-x64-189/build M=/home/admin/ninoop-module modules
make[1]: Entering directory '/lib/modules/4.14.87-rt49-cg-7.0.0f0-x64-189/build'
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (       \
echo >&2;                                                       \
echo >&2 "  ERROR: Kernel configuration is invalid.";           \
echo >&2 "         include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it.";      \
echo >&2 ;                                                      \
/bin/false)
mkdir -p /home/admin/ninoop-module/.tmp_versions ; rm -f /home/admin/ninoop-module/.tmp_versions/*
make -f ./scripts/Makefile.build obj=/home/admin/ninoop-module
make[2]: *** No rule to make target 'tools/objtool/objtool', needed by '/home/admin/ninoop-module/ninoop.o'.  Stop.
make[1]: *** [Makefile:1532: _module_/home/admin/ninoop-module] Error 2
make[1]: Leaving directory '/lib/modules/4.14.87-rt49-cg-7.0.0f0-x64-189/build'
make: *** [Makefile:8: all] Error 2

 When I run make prepare I get the 3rd error from the original post

[smithedtes]

Is there any expectation that compiling kernel modules on-target is supported? In the past with regular shared libraries I've had the experience that on-target compilation is many times easier than the cross compilation. Is this not possible for kernel modules?

[GatorChomp]

Hi smithedtes,

I haven't personally followed Brad's tutorial, but on a clean system without modification I've been able to build simple "Hello, World!" modules without issue following standard practices. It should work. 

Note that you'll need make, kernel-dev, gcc, and the other typical tools required for kernel modules. I'd also point out that Brad's Makefile example appears to be configured for cross-compiling on a Linux Desktop machine and may be slightly different from what it would be on target (as you've noticed). Have you tried something a bit more simple? Eg:

obj-m := nioop.o
KVERSION := $(shell uname -r)

all:
	$(MAKE) -C /lib/modules/$(KVERSION)/build M=$(PWD) modules
clean: 
	$(MAKE) -C /lib/modules/$(KVERSION)/build M=$(PWD) clean

[smithedtes]

Thanks for following up Charlie, I'm fairly certain I've just run the make command you show in your file by hand based on some 3rd party tutorials and I had the same issue. It always hits that segfault.

When you did yours, which version of nilrt did you use?...I just went into max and the available options changed. Originally for formatting the disk I only had the option for some sort of systemlink image. Now I have "PXI System Image for Q3 2019"...I'll reformat and see if that fixes things.

[smithedtes]

Ok, so I'm running your suggested makefile ("nioop.o" should be "ninoop.o" if you try it yourself). Now I'm getting the following:

make -C /lib/modules/4.14.87-rt49-cg-7.1.0f0-x64-41/build M= modules
make[1]: Entering directory '/lib/modules/4.14.87-rt49-cg-7.1.0f0-x64-41/build'
make[2]: *** No rule to make target 'arch/x86/entry/syscalls/syscall_32.tbl', needed by 'arch/x86/include/generated/asm/syscalls_32.h'.  Stop.
make[1]: *** [arch/x86/Makefile:257: archheaders] Error 2
make[1]: Leaving directory '/lib/modules/4.14.87-rt49-cg-7.1.0f0-x64-41/build'
make: *** [Makefile:5: all] Error 2

I've installed kernel-dev and the dev packagegroups but I'm clearly missing something. I've attached my installed package list (opkg list-installed > opkg.txt) if you wouldn't mind taking a second? Or if you could do the same and send it my way for comparison?

Thanks,

Daniel

[smithedtes]

I tried copying the 19.0/4.14 kernel source from github into /lib/modules/4.14..../build (NOT overwriting anything already there) and that got me a lot further ...but still back to the segmentation fault for objtool check.

[GatorChomp · Accepted solution]

You shouldn't need to download the kernel source for an on-target compilation of an out-of-tree module (which the example is). The kernel headers should be sufficient. Looking at the PXI Linux RT System Image for Q1 2019, that image actually appears to already include everything you need (make, kernel-dev (the headers), gcc, kmod, etc). 

Note: Brad's example is meant to demonstrate debugging as well and has a deliberate error in it. To get the cat /dev/ninoop command to work below you'll need to fix that as discussed around the 17 minute mark in his video. 

Here's the steps I took to get things working on a PXIe-8880:

1. Installed the System Image for Q1 2019.
2. Installed LabVIEW Real-Time to the controller (not actually convinced this is necessary)
3. Used wget to pull down the ninoop source and extracted it to /home/admin which created the /home/admin/ninoop-module/ directory.
4. Ran make inside that new directory with the modified make file I described above (including your correction).
   

This should create ninoop.ko in that directory. After doing so, I did the following:

1. Confirmed the module binary was present.
2. Ran "insmod ninoop.ko"
3. cat /dev/ninoop

Give that a try. 

[smithedtes]

Thanks for your help...I had to fight some fires yesterday and today and now I can't get my crio PXI to show up in max so I may be another day, but I appreciate your assistance.

[smithedtes]

OK, I reflashed it and you're right, it seemed to work. Perhaps something in one of the dev packages I installed is causing the problem...

In any case, thanks again for your assistance with this 🙂