Howto resolve a function name conflict when compiling a kernel module - c

I'm trying to compile a 3rd party kernel module for RHEL 5.6 and it is failing due to function name conflicts with mutex_acquire and mutex_release. This kernel module compiles cleanly on RHEL 4.7 so something changed between kernels 2.6.9 and 2.6.18. Sadly, this kernel module is no longer supported by the vendor but I do have the source code for mutex.c and mutex.h which define these functions. Unfortunately there is an object file nivxi.o upon which no source code is distributed and this object file is calling mutex_acquire and mutex_release so I cannot just simply alter their names.
As an aside, I originally attempted to just modify the names slightly and the compile errors went away but when it went to make the .ko kernel module it complained that it couldn't find mutex_acquire or mutex_release; presumably due to nivxi.o
How do I force the compiler/linker to use the function definitions in my local .c/.h files even though they trounce over like-named functions elsewhere?
mutex.h
NIVXICC void mutex_acquire(mutex_t *mutex);
NIVXICC void mutex_release(mutex_t *mutex);
nivxicc.h (just incase this is pertinent)
#ifndef NIVXICC_H
#define NIVXICC_H
#define NIVXICC __attribute__((regparm(0))) __attribute__((cdecl))
#endif
/usr/include/lockdep.h (conflicting definition)
#ifdef CONFIG_DEBUG_LOCK_ALLOC
# ifdef CONFIG_PROVE_LOCKING
# define mutex_acquire(l, s, t, i) lock_acquire(l, s, t, 0, 2, i)
# else
# define mutex_acquire(l, s, t, i) lock_acquire(l, s, t, 0, 1, i)
# endif
# define mutex_release(l, n, i) lock_release(l, n, i)
#else
# define mutex_acquire(l, s, t, i) do { } while (0)
# define mutex_release(l, n, i) do { } while (0)
#endif
Error
# make
make -C /lib/modules/2.6.18-238.el5/build SUBDIRS=/usr/local/nivxi/src KBUILD_VERBOSE=1 modules
make[1]: Entering directory `/usr/src/kernels/2.6.18-238.el5-i686'
test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \
echo; \
echo " ERROR: Kernel configuration is invalid."; \
echo " include/linux/autoconf.h or include/config/auto.conf are missing."; \
echo " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
echo; \
/bin/false)
mkdir -p /usr/local/nivxi/src/.tmp_versions
rm -f /usr/local/nivxi/src/.tmp_versions/*
make -f scripts/Makefile.build obj=/usr/local/nivxi/src
gcc -m32 -Wp,-MD,/usr/local/nivxi/src/.vxi.o.d -nostdinc -isystem \
/usr/lib/gcc/i386-redhat-linux/4.1.2/include -D__KERNEL__ -Iinclude \
-include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes \
-Wno-trigraphs -fno-strict-aliasing -fno-common -Wstrict-prototypes \
-Wundef -Werror-implicit-function-declaration \
-fno-delete-null-pointer-checks -fwrapv -Os -pipe -msoft-float \
-fno-builtin-sprintf -fno-builtin-log2 -fno-builtin-puts \
-mpreferred-stack-boundary=2 -march=i686 -mtune=generic -mtune=generic \
-mregparm=3 -ffreestanding -Iinclude/asm-i386/mach-generic \
-Iinclude/asm-i386/mach-default -fomit-frame-pointer -g -fno-stack-protector \
-Wdeclaration-after-statement -Wno-pointer-sign -DVXI_MAJOR=0 \
-DREMAP_PAGE_RANGE_VMA -D__DEBUG__ -DMODULE -D"KBUILD_STR(s)=#s" \
-D"KBUILD_BASENAME=KBUILD_STR(vxi)" -D"KBUILD_MODNAME=KBUILD_STR(vximod)" \
-c -o /usr/local/nivxi/src/.tmp_vxi.o /usr/local/nivxi/src/vxi.c
In file included from /usr/local/nivxi/src/vxi.c:13:
/usr/local/nivxi/src/mutex.h:59:42: error: macro "mutex_acquire" requires 4 arguments, but only 1 given
In file included from /usr/local/nivxi/src/vxi.c:13:
/usr/local/nivxi/src/mutex.h:59: warning: ‘regparm’ attribute only applies to function types
/usr/local/nivxi/src/mutex.h:59: warning: ‘cdecl’ attribute only applies to function types
/usr/local/nivxi/src/mutex.h:61:42: error: macro "mutex_release" requires 3 arguments, but only 1 given
/usr/local/nivxi/src/mutex.h:61: warning: ‘regparm’ attribute only applies to function types
/usr/local/nivxi/src/mutex.h:61: warning: ‘cdecl’ attribute only applies to function types
/usr/local/nivxi/src/vxi.c:128:31: error: macro "mutex_acquire" requires 4 arguments, but only 1 given
/usr/local/nivxi/src/vxi.c:133:31: error: macro "mutex_release" requires 3 arguments, but only 1 given
/usr/local/nivxi/src/vxi.c:146:31: error: macro "mutex_acquire" requires 4 arguments, but only 1 given
/usr/local/nivxi/src/vxi.c:158:31: error: macro "mutex_release" requires 3 arguments, but only 1 given
/usr/local/nivxi/src/vxi.c: In function ‘vxi_mmap’:
/usr/local/nivxi/src/vxi.c:243: error: implicit declaration of function ‘remap_page_range’
make[2]: *** [/usr/local/nivxi/src/vxi.o] Error 1
make[1]: *** [_module_/usr/local/nivxi/src] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.18-238.el5-i686'
make: *** [default] Error 2

The problem will not be in your object file as macros have file-scope and are replaced by the preprocessor. Thus after being compiled, the macro no longer exists as far as your nivxi.o file is concerned.
The issue is probably in your mutex.h file. I would look at the top and you will likely see an #include <lockdep.h> line. Thus once the preprocessor gets down to your function definition, it treats mutex_acquire as a token to be replaced (with the wrong number of arguments).
The easiest way to solve your problem will be to #undef mutex_acquire and #undef mutex_release at the beginning of mutex.h. This will prevent the preprocessor from replacing the tokens in your mutex.h. Since defines have file-scope, you don't need to worry about this propagating beyond your application

Related

Failed to compile bindsnoop eBPF c code outside of kernel tree

I'm trying to build a BPF program written in C into the bpf bytecode. The program C code was taken from https://github.com/iovisor/bcc/blob/master/tools/bindsnoop.py (I used C code from bpf_text with some customizations).
I didn't want to use bcc python tools, my purpose is to write both kernel and user space code in C, and I would like to build a kernel program outside of the kernel tree.
I use Ubuntu 20.10 and here is uname -a output:
Linux bb-VirtualBox 5.8.0-63-generic #71-Ubuntu SMP Tue Jul 13 15:59:12 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Linux headers are installed, but for some reason I have two directories containing linux headers for 5.8.0-63:
/usr/src/linux-headers-5.8.0-63
and
/usr/src/linux-headers-5.8.0-63-generic
I used this post to create a makefile for my program: https://blogs.oracle.com/linux/post/bpf-in-depth-building-bpf-programs
so the makefile looks like below:
OBJS = kprobe_bindsnoop_kern.o
LLC ?= llc
CLANG ?= clang
INC_FLAGS = -nostdinc -isystem `$(CLANG) -print-file-name=include`
EXTRA_CFLAGS ?= -O2 -emit-llvm
linuxhdrsgen ?= /usr/src/linux-headers-5.8.0-63-generic
LINUXINCLUDE = -I$(linuxhdrsgen)/arch/x86/include \
-I$(linuxhdrsgen)/arch/x86/include/generated/uapi \
-I$(linuxhdrsgen)/arch/x86/include/generated \
-I$(linuxhdrsgen)/arch/x86/include/uapi \
-I$(linuxhdrsgen)/arch/x86/include/generated/uapi \
-I$(linuxhdrsgen)/include/uapi \
-I$(linuxhdrsgen)/include/generated/uapi \
-I$(linuxhdrsgen)/include \
-include ${linuxhdrsgen}/include/linux/kconfig.h
all: $(OBJS)
.PHONY: clean
clean:
rm -f $(OBJS)
INC_FLAGS = -nostdinc -isystem `$(CLANG) -print-file-name=include`
$(OBJS): %.o:%.c
$(CLANG) $(INC_FLAGS) \
-D__KERNEL__ -D__ASM_SYSREG_H \
-Wno-unused-value -Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-I../include $(LINUXINCLUDE) \
$(EXTRA_CFLAGS) -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $#
And kprobe_bindsnoop_kern.c starts from the following set of include files:
#include <uapi/linux/ptrace.h>
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wtautological-compare"
#include <net/sock.h>
#pragma clang diagnostic pop
#include <net/inet_sock.h>
#include <net/net_namespace.h>
#include <bcc/proto.h>
Below you can see the compilation output:
clang -nostdinc -isystem `clang -print-file-name=include` \
-D__KERNEL__ -D__ASM_SYSREG_H \
-Wno-unused-value -Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-I../include -I/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/ -I/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/generated/uapi -I/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/generated/ -I/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/uapi -I/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/generated/uapi -I/usr/src/linux-headers-5.8.0-63-generic/include/uapi -I/usr/src/linux-headers-5.8.0-63-generic/include/generated/uapi -I/usr/src/linux-headers-5.8.0-63-generic/include -include /usr/src/linux-headers-5.8.0-63-generic/include/linux/kconfig.h \
-O2 -emit-llvm -c kprobe_bindsnoop_kern.c -o -| llc -march=bpf -filetype=obj -o kprobe_bindsnoop_kern.o
In file included from kprobe_bindsnoop_kern.c:22:
In file included from /usr/src/linux-headers-5.8.0-63-generic/include/uapi/linux/ptrace.h:143:
In file included from /usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/ptrace.h:5:
In file included from /usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/segment.h:6:
/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/alternative.h:59:2: error: unknown type name 's32'
s32 instr_offset; /* original instruction */
^
/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/alternative.h:60:2: error: unknown type name 's32'
s32 repl_offset; /* offset to replacement instruction */
^
/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/alternative.h:61:2: error: unknown type name 'u16'
u16 cpuid; /* cpuid bit set for replacement */
^
/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/alternative.h:62:2: error: unknown type name 'u8'
u8 instrlen; /* length of original instruction */
^
/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/alternative.h:63:2: error: unknown type name 'u8'
u8 replacementlen; /* length of new instruction */
^
/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/alternative.h:64:2: error: unknown type name 'u8'
u8 padlen; /* length of build-time padding */
^
/usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/alternative.h:85:8: error: unknown type name 'bool'
extern bool skip_smp_alternatives;
^
In file included from kprobe_bindsnoop_kern.c:22:
In file included from /usr/src/linux-headers-5.8.0-63-generic/include/uapi/linux/ptrace.h:143:
In file included from /usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/ptrace.h:5:
In file included from /usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/segment.h:169:
In file included from /usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/cache.h:5:
In file included from /usr/src/linux-headers-5.8.0-63-generic/include/linux/linkage.h:7:
In file included from /usr/src/linux-headers-5.8.0-63-generic/include/linux/export.h:43:
In file included from /usr/src/linux-headers-5.8.0-63-generic/include/linux/compiler.h:266:
/usr/src/linux-headers-5.8.0-63-generic/include/linux/kasan-checks.h:16:15: error: unknown type name 'bool'
static inline bool __kasan_check_read(const volatile void *p, unsigned int size)
^
/usr/src/linux-headers-5.8.0-63-generic/include/linux/kasan-checks.h:18:9: error: use of undeclared identifier 'true'
return true;
^
/usr/src/linux-headers-5.8.0-63-generic/include/linux/kasan-checks.h:20:15: error: unknown type name 'bool'
static inline bool __kasan_check_write(const volatile void *p, unsigned int size)
^
/usr/src/linux-headers-5.8.0-63-generic/include/linux/kasan-checks.h:22:9: error: use of undeclared identifier 'true'
return true;
^
/usr/src/linux-headers-5.8.0-63-generic/include/linux/kasan-checks.h:34:15: error: unknown type name 'bool'
static inline bool kasan_check_read(const volatile void *p, unsigned int size)
^
/usr/src/linux-headers-5.8.0-63-generic/include/linux/kasan-checks.h:36:9: error: use of undeclared identifier 'true'
return true;
^
/usr/src/linux-headers-5.8.0-63-generic/include/linux/kasan-checks.h:38:15: error: unknown type name 'bool'
static inline bool kasan_check_write(const volatile void *p, unsigned int size)
^
/usr/src/linux-headers-5.8.0-63-generic/include/linux/kasan-checks.h:40:9: error: use of undeclared identifier 'true'
return true;
^
In file included from kprobe_bindsnoop_kern.c:22:
In file included from /usr/src/linux-headers-5.8.0-63-generic/include/uapi/linux/ptrace.h:143:
In file included from /usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/ptrace.h:5:
In file included from /usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/segment.h:169:
In file included from /usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/cache.h:5:
In file included from /usr/src/linux-headers-5.8.0-63-generic/include/linux/linkage.h:7:
In file included from /usr/src/linux-headers-5.8.0-63-generic/include/linux/export.h:43:
In file included from /usr/src/linux-headers-5.8.0-63-generic/include/linux/compiler.h:267:
/usr/src/linux-headers-5.8.0-63-generic/include/linux/kcsan-checks.h:148:67: error: unknown type name 'size_t'
static inline void __kcsan_check_access(const volatile void *ptr, size_t size,
^
/usr/src/linux-headers-5.8.0-63-generic/include/linux/kcsan-checks.h:164:53: error: unknown type name 'size_t'
kcsan_begin_scoped_access(const volatile void *ptr, size_t size, int type,
^
/usr/src/linux-headers-5.8.0-63-generic/include/linux/kcsan-checks.h:184:65: error: unknown type name 'size_t'
static inline void kcsan_check_access(const volatile void *ptr, size_t size,
^
In file included from kprobe_bindsnoop_kern.c:22:
In file included from /usr/src/linux-headers-5.8.0-63-generic/include/uapi/linux/ptrace.h:143:
In file included from /usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/ptrace.h:6:
In file included from /usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/page_types.h:7:
In file included from /usr/src/linux-headers-5.8.0-63-generic/include/linux/mem_encrypt.h:17:
In file included from /usr/src/linux-headers-5.8.0-63-generic/arch/x86/include/asm/mem_encrypt.h:15:
/usr/src/linux-headers-5.8.0-63-generic/include/linux/init.h:155:8: error: unknown type name 'bool'
extern bool rodata_enabled;
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
I tried to add
#include <linux/types.h> or
#include <asm/types.h>
but it doesn't help.
I checked many posts, like this
Error compiling eBPF C code out of kernel tree
and this
how to build BPF program out of the kernel tree
but still failed to get answer.
What am I missing?
Any help will be greatly appreciated ))
Thanks to everyone who tried to help me!
Finally the issue was sooooo simple - just needed to change an order of the include directories specified in the makefile.
Just moved "-I$(linuxhdrsgen)/include" to be the first in the list and it solved the issue.
Meaning, now the list of include dirs looks as follows:
LINUXINCLUDE = -I$(linuxhdrsgen)/include
-I$(linuxhdrsgen)/arch/x86/include
-I$(linuxhdrsgen)/arch/x86/include/generated/uapi
-I$(linuxhdrsgen)/arch/x86/include/generated
-I$(linuxhdrsgen)/arch/x86/include/uapi
-I$(linuxhdrsgen)/arch/x86/include/generated/uapi
-I$(linuxhdrsgen)/include/uapi
-I$(linuxhdrsgen)/include/generated/uapi
-include ${linuxhdrsgen}/include/linux/kconfig.h

asm keyword as identifier name in C?

I've seen a project which uses the asm keyword as variable name and the code compiles fine with the provided Makefile on Linux:
int
main(int ac, char *av[])
{
struct TMap *tm;
FILE *inf, *hf;
char *f, *sep;
int c, asm; // <---
asm = Defasm;
// ...
}
Here is the entire Makefile:
BIN = qbe
V = #
OBJDIR = obj
SRC = main.c util.c parse.c cfg.c mem.c ssa.c alias.c load.c copy.c \
fold.c live.c spill.c rega.c gas.c
AMD64SRC = amd64/targ.c amd64/sysv.c amd64/isel.c amd64/emit.c
ARM64SRC = arm64/targ.c arm64/abi.c arm64/isel.c arm64/emit.c
SRCALL = $(SRC) $(AMD64SRC) $(ARM64SRC)
AMD64OBJ = $(AMD64SRC:%.c=$(OBJDIR)/%.o)
ARM64OBJ = $(ARM64SRC:%.c=$(OBJDIR)/%.o)
OBJ = $(SRC:%.c=$(OBJDIR)/%.o) $(AMD64OBJ) $(ARM64OBJ)
CFLAGS += -Wall -Wextra -std=c99 -g -pedantic
$(OBJDIR)/$(BIN): $(OBJ) $(OBJDIR)/timestamp
#test -z "$(V)" || echo "ld $#"
$(V)$(CC) $(LDFLAGS) $(OBJ) -o $#
$(OBJDIR)/%.o: %.c $(OBJDIR)/timestamp
#test -z "$(V)" || echo "cc $<"
$(V)$(CC) $(CFLAGS) -c $< -o $#
$(OBJDIR)/timestamp:
#mkdir -p $(OBJDIR)
#mkdir -p $(OBJDIR)/amd64
#mkdir -p $(OBJDIR)/arm64
#touch $#
$(OBJ): all.h ops.h
$(AMD64OBJ): amd64/all.h
$(ARM64OBJ): arm64/all.h
obj/main.o: config.h
config.h:
#case `uname` in \
*Darwin*) \
echo "#define Defasm Gasmacho"; \
echo "#define Deftgt T_amd64_sysv"; \
;; \
*) \
echo "#define Defasm Gaself"; \
case `uname -m` in \
*aarch64*) \
echo "$define Deftgt T_arm64"; \
;; \
*) \
echo "#define Deftgt T_amd64_sysv";\
;; \
esac \
;; \
esac > $#
install: $(OBJDIR)/$(BIN)
mkdir -p "$(DESTDIR)/$(PREFIX)/bin/"
cp $< "$(DESTDIR)/$(PREFIX)/bin/"
uninstall:
rm -f "$(DESTDIR)/$(PREFIX)/bin/$(BIN)"
clean:
rm -fr $(OBJDIR)
clean-gen: clean
rm -f config.h
check: $(OBJDIR)/$(BIN)
tools/test.sh all
check-arm64: $(OBJDIR)/$(BIN)
TARGET=arm64 tools/test.sh all
src:
#echo $(SRCALL)
80:
#for F in $(SRCALL); \
do \
awk "{ \
gsub(/\\t/, \" \"); \
if (length(\$$0) > $#) \
printf(\"$$F:%d: %s\\n\", NR, \$$0); \
}" < $$F; \
done
.PHONY: clean clean-gen check check-arm64 src 80 install uninstall
I'm wondering how to accomplish that the compiler will allow asm as variable name (ignoring the fact that it's bad style to do this). I tried porting the Makefile to a CMakeLists.txt but the compiler threw an error because of the invalid usage of asm. How to fix this without changing the code? I already forced the C99 standard as the Makefile did and used the same C compiler flags but that didn't help:
cmake_minimum_required(VERSION 3.10.2)
project(qbe C)
set(CMAKE_C_STANDARD 99)
set(CMAKE_C_FLAGS "-Wall -Wextra -std=c99 -g -pedantic")
include_directories(amd64)
add_executable(qbe
amd64/all.h
amd64/emit.c
amd64/isel.c
amd64/sysv.c
amd64/targ.c
alias.c
all.h
cfg.c
copy.c
fold.c
gas.c
live.c
load.c
main.c
mem.c
ops.h
parse.c
rega.c
spill.c
ssa.c
util.c)
I want to use CMake due to IDE support.
asm is not a keyword of standard C, nor a reserved identifier, though the standard recognizes it as a common extension. The standard furthermore remarks that
The inclusion of any extension that may cause a strictly conforming
program to become invalid renders an implementation nonconforming.
Examples of such extensions are new keywords, extra library functions
declared in standard headers, or predefined macros with names that do
not begin with an underscore.
This is in Annex J, which is non-normative, but it merely summarizes a conclusion that can be drawn from the normative text. Thus a conforming implementation will not reject code on the basis that it uses asm as an identifier.
I find that GCC, for example, accepts usage of asm as an identifier when any of the strict conformance modes it supports is used (-std=c89 or -std=c99 or -std=c11), but rejects it with an error by default or with GNU extensions specifically enabled (e.g. with -std=gnu11). If you are using a different compiler then you will need to consult its documentation for how to obtain conformance to the standard in this area, if indeed it is possible to do so.
Addendum
As for why your CMake attempt is failing, the CMAKE_C_STANDARD property does not do what you seem to think it does. Its tells CMake to choose, if possible, compiler options that provide the features of the specified version of the C standard, but it does not request strict conformance to that standard. The docs specifically postulate it causing the -std=gnu11 option to be used under some circumstances, and that or similar inclusive options would have an effect opposite to what you want.
asm is not a standard C keyword. A conforming C compiler may not refuse compiling a program that uses asm as an identifier.
Choosing a standard explicitly with -std=c99 will also remove asm keyword. You can continue to use __asm__ however, since all names beginning with two underscores are always reserved by the implementation for any use.
However, it is still very bad style, since C99, C11 and C17 revisions do mention it as a common extension.

Macro defined in main.c not visible in another included file

I have multiple C and H files
In main.c I defined a macro, and in ws_driver.c I want to use it.
ws_driver.h is included in main.c.
main.c
#define WS_PORT PORT_D8
#define WS_BIT D8
#define WS_DDR DDR_D8
#include "ws_driver.h"
In ws_dirver.c I have two checks:
ws_driver.c
#include "ws_driver.h"
#ifndef WS_PORT
# error "WS_PORT not defined!"
#endif
#ifndef WS_BIT
# error "WS_BIT not defined!"
#endif
Both are failing.
$ avr-gcc -std=gnu99 -mmcu=atmega328p -DF_CPU=16000000UL -Os -I. -I -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wno-main -Wno-strict-prototypes -Wno-comment -g2 -ggdb -ffunction-sections -fdata-sections -Wl,--gc-sections -Wl,--relax -std=gnu99 main.c ws_driver.c --output main.elf
ws_driver.c:10:3: error: #error "WS_PORT not defined!"
# error "WS_PORT not defined!"
^
ws_driver.c:14:3: error: #error "WS_BIT not defined!"
# error "WS_BIT not defined!"
^
ws_driver.c: In function 'ws_show':
ws_driver.c:23:20: error: 'WS_PORT' undeclared (first use in this function)
#define bus_low() (WS_PORT) &= ~(1 << WS_BIT)
^
ws_driver.c:37:2: note: in expansion of macro 'bus_low'
bus_low();
^
ws_driver.c:23:20: note: each undeclared identifier is reported only once for each function it appears in
#define b......
What am I doing wrong? Please ask if you want to see some other part of the code.
You have to define the macros in a header file, not in the .c file if you want to use them in multiple places.
When the compiler compiles ws_driver.c it only includes ws_driver.h and the macro is not there. It does not include main.c. Each .c file is compiled separately.
Move the macro definitions in say config.h and include it everywhere you need it.
You can also use the compiler's define -DWS_BIT=123 -DOTHER=SMTH. The value you pass will be in the generated object file and can not be changed without recompiling.
If you want to compile only once, then pass these as parameters or create a configure_my_library() function...

Can't find a unistd.h with uuid_t typedef

Trying to build vSphere Perl SDK on Centos 2.6. Got all dependencies except one, namely UUID-0.05.
The problem seems to be that the uuid.h include file references unistd.h for the definition of uuid_t, but unistd.h has no such thing. Worse, though some people have described a conflict between the two include files for the variable, I cannot find a unistd.h file on the Internet with the definition.
Can someone point to such a unistd.h file? Or, even, a better approach to take?
Here's some info about the original issue:
In Changelog for uuid.1.6.2:
o Apply workaround to uuid.h to avoid conflicts with
vendor UUID implementations where uuid_t (Darwin/MacOSX)
or uuid_create/uuid_compare (POSIX) might exist.
[Ralf S. Engelschall]
In uuid.h:
/* workaround conflicts with system headers */
#define uuid_t __vendor_uuid_t
#define uuid_create __vendor_uuid_create
#define uuid_compare __vendor_uuid_compare
#include <sys/types.h>
#include <unistd.h>
#undef uuid_t
#undef uuid_create
#undef uuid_compare
Here's the original problem (compiling):
jloiacon#flowviewerprime /home/jloiacon/UUID-0.05 249 >make
cp UUID.pm blib/lib/UUID.pm
/usr/bin/perl /usr/share/perl5/ExtUtils/xsubpp -typemap /usr/share/perl5/ExtUtils/typemap UUID.xs > UUID.xsc && mv UUID.xsc UUID.c
gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DVERSION=\"0.05\" -DXS_VERSION=\"0.05\" -fPIC "-I/usr/lib64/perl5/CORE" UUID.c
UUID.xs: In function âdo_generateâ:
UUID.xs:13: error: storage size of âuuidâ isnât known
UUID.xs:14: warning: implicit declaration of function âuuid_generateâ
UUID.xs:13: warning: unused variable âuuidâ
UUID.xs: In function âdo_unparseâ:
UUID.xs:20: error: storage size of âuuidâ isnât known
UUID.xs:23: warning: implicit declaration of function âuuid_unparseâ
UUID.xs:20: warning: unused variable âuuidâ
UUID.xs: In function âdo_parseâ:
UUID.xs:29: error: storage size of âuuidâ isnât known
UUID.xs:33: warning: implicit declaration of function âuuid_parseâ
UUID.xs:30: warning: unused variable âstrâ
UUID.xs:29: warning: unused variable âuuidâ
make: *** [UUID.o] Error 1
Thanks
Install uuid-c++-devel.
lorem ipsum

Error: could not insert module. Unknown symbol in module

I'm trying to port RR0D Rasta Ring0 Debugger from 32-bit Linux to 64-bit Linux. I have converted 32-bit gcc inline assembly to 64-bit using vim regex as mentioned in my question: How to convert Linux 32-bit gcc inline assembly to 64-bit code?
I'm using gcc with -m64 flag. The target environment is Linux x86-64, custom kernel version 3.5.5.
The Makefile is the following:
EXTRA_CFLAGS += -O2 -Wall -DLINUX_26 -m64
OBJ := module_nux.o breakpoint.o buffering.o command.o disasmbak.o idt.o
OBJ += keyboard.o page.o video.o utils.o import_symb.o core_rr0d.o pci.o
MODULE := rr0d.o
obj-m := $(MODULE)
rr0d-objs := $(OBJ)
default:
make -C /lib/modules/`uname -r`/build/ SUBDIRS=`pwd` modules
clean:
rm -f *.o .*.o.cmd .*.ko.cmd *.mod.c *~
rm -rf .tmp_versions
mrproper:
make clean
rm -f *.ko
make gives a lot of warnings like warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] and warning: cast from pointer to integer of different size [-Wpointer-to-int-cast], but these are probably irrelevant to the topic.
The last rows of the output of make are probably the important ones:
/home/user/code/rr0d/0.3/core_rr0d.c: In function ‘cleanup_rr0d’:
/home/user/code/rr0d/0.3/core_rr0d.c:1938:36: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
CC [M] /home/user/code/rr0d/0.3/pci.o
LD [M] /home/user/code/rr0d/0.3/rr0d.o
Building modules, stage 2.
MODPOST 1 modules
WARNING: "RING_HOOO_SEGMENT" [/home/user/code/rr0d/0.3/rr0d.ko] undefined!
CC /home/user/code/rr0d/0.3/rr0d.mod.o
LD [M] /home/user/code/rr0d/0.3/rr0d.ko
make[1]: Leaving directory `/home/user/code/kernel/linux-3.5.5'
So, RING_HOOO_SEGMENT is undefined.
When I try to insmod the module with insmod ./rr0d.ko as root, I get:
Error: could not insert module ./rr0d.ko: Unknown symbol in module
Checking with dmesg | tail -n 1 gives the following output:
[15975.412346] rr0d: Unknown symbol RING_HOOO_SEGMENT (err 0)
So, the unknown symbol definitively is RING_HOOO_SEGMENT.
RING_HOOO_SEGMENT is a constant created with #define in vars.h, that is included in several .c files with #include "vars.h".
The essential #ifdef block of vars.h with #define RING_HOOO_SEGMENT is this one:
#ifdef LINUX_26
#define fake_naked
#if defined(__GNUC__)
// the line below is the important one.
#define RING_HOOO_SEGMENT "$0x7b"
//#define RING_HOOO_SEGMENT "$0x60"
#elif defined(_MSC_VER)
#define RING_HOOO_SEGMENT 0x7b
#endif
#else /* LINUX_24 */
#define fake_naked _asm_("\t" \
"add $0x08, %esp\n\t" \
"popl %ebp\n" \
);
#if defined(__GNUC__)
#define RING_HOOO_SEGMENT "$0x18"
#elif defined(_MSC_VER)
#define RING_HOOO_SEGMENT 0x18
#endif
#define RING_HOOO_SEGMENT_VALUE 0x18
#endif /* LINUX_26 */
Obviously if #define RING_HOOO_SEGMENT "$0x7b" (in #if defined(__GNUC__) inside #ifdef LINUX_26) is commented out, the code won't compile, so it's clear that RING_HOOO_SEGMENT gets defined.
Grepping for RING_HOOO_SEGMENT gives the following matches:
$ grep 'RING_HOOO_SEGMENT' *.c *.o *.ko
core_rr0d.c: "movq RING_HOOO_SEGMENT, %rax\n\t"\
core_rr0d.c: __asm{ movq RING_HOOO_SEGMENT, %rax}\
Binary file rr0d.ko matches
Both core_rr0d.c rows are inline assembly. core_rr0d.c contains #include "vars.h" so that should be fine.
Also the binary module rr0d.ko matches, so it contains the string RING_HOOO_SEGMENT (in some form), even if insmod ./rr0d.ko fails with Error: could not insert module ./rr0d.ko: Unknown symbol in module.
Any ideas what might the reason for this problem and how to proceed to be able to insmod the module?
core_rr0d.c: "movq RING_HOOO_SEGMENT, %rax\n\t"\
Here RING_HOOO_SEGMENT is in a string (probably part of an inline assembler block). As such, the preprocessor will not substitute RING_HOOO_SEGMENT, and it gets passed as-is to the assembler, where the definition of RING_HOOO_SEGMENT is not available.
Fortunately, RING_HOOO_SEGMENT is itself defined as the string "$0x7b", so we can use compile-time string concatenation:
"movq " RING_HOOO_SEGMENT ", %rax\n\t"\
The preprocessor will substitute RING_HOOO_SEGMENT for "$0x7b", then GCC will concatenate these strings before passing it down to the assembler.

Resources