euspectre/kedr

(Fixed in KEDR 0.4) KEDR fails to build for kernel 3.3.0

euspectre opened this issue · 4 comments

Original issue 5 created by euspectre on 2012-03-20T06:59:33.000Z:

When building KEDR 0.3 on the Linux kernel 3.3.0, compilation fails with the following error:


[ 63%] Generating kedr_cm_schedule.ko, Module.symvers
Generating kedr_cm_vmm.ko, Module.symvers
Generating kedr_cm_cmm.ko, Module.symvers
[ 63%] Generating kedr_leak_check.ko, Module.symvers
/opt/kedr/payloads_callm/waitqueue/functions_support.c: In function 'kedr_intermediate_func___init_waitqueue_head':
/opt/kedr/payloads_callm/waitqueue/functions_support.c:96: warning: passing argument 2 of '__init_waitqueue_head' from incompatible pointer type
include/linux/wait.h:80: note: expected 'const char ' but argument is of type 'struct lock_class_key *'
/opt/kedr/payloads_callm/waitqueue/functions_support.c:96: error: too few arguments to function '__init_waitqueue_head'
make[4]: *
* [/opt/kedr/payloads_callm/waitqueue/functions_support.o] Error 1
make[3]: *** [module/opt/kedr/payloads_callm/waitqueue] Error 2
make[2]: *** [payloads_callm/waitqueue/kedr_cm_waitqueue.ko] Error 2
make[1]: *** [payloads_callm/waitqueue/CMakeFiles/kedr_cm_waitqueue.dir/all] Error 2

make[1]: *** Waiting for unfinished jobs....

It seems that the signature of __init_waitqueue_head changed in the kernel 3.3.0:

void __init_waitqueue_head(wait_queue_head_t *q, const char *name, struct lock_class_key *key)

In the kernel 3.2.x and earlier, it has no 'name' argument:
void __init_waitqueue_head(wait_queue_head_t *q, struct lock_class_key *key)

The problem seems to affect call tracing facilities only. If they are not used, one can disable them when configuring KEDR, as a temporary workaround:

cmake -DKEDR_STANDARD_CALLM_PAYLOADS=off
<other_options_if_needed> <path_to_kedr_source_tree>

Comment #1 originally posted by euspectre on 2012-08-13T14:33:52.000Z:

Fixed in the repository.

Comment #2 originally posted by euspectre on 2012-08-13T14:35:05.000Z:

<empty>

Comment #3 originally posted by euspectre on 2012-08-13T14:37:42.000Z:

<empty>

Comment #4 originally posted by euspectre on 2012-09-27T14:10:34.000Z:

<empty>