Hi Lin ! On Tue, 2009-08-04 at 21:54 +0800, Pei Lin wrote: > Do u notice the macro " #ifdef __KERNEL__ " in these headers? > u compile the kernel it will declare this macro. > give a web link i think maybe it can give u some help. > http://www.linuxforums.org/forum/linux-programming-scripting/54130-inclusion-kernel-header-files.html > > BRs > Lin > > 2009/8/1 Microbit_Ubuntu <microbit@xxxxxxxxxxxxxxxxxxxxxx>: > > On Fri, 2009-07-31 at 08:53 +1000, Microbit_Ubuntu wrote: > >> Hi all, > >> > >> I'm a bit confused as to the status of the type 'u32' in the kernel I > >> use (2.6.29.4). > >> u32 is used in thread_info.h, but types.h uses __u32. > >> > >> Now, while googling I came across a recent patch - > >> {Mon Feb 09 2009 Chuck Ebbert <cebbert@xxxxxxxxxx> +- Fix type in header > >> so iptables will build. (#484679) } > >> Although not related, it's the same issue - the patch applies a change > >> from u32 to __u32. > >> > >> Should I change the type u32 -> __u32 in thread_info.h ??? > >> I'm not comfortable with that because that's "stable" kernel source. > >> > >> Or am I simply overlooking some runtime constant/defintion I should have > >> present... > >> I can't see why that would be, I've built various modules before, never > >> had an issue like this.. ? > >> > >> > >> For reference, this is the chain (module.h -> downwards) - that causes > >> the error : > >> > >> In file included > >> from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/preempt.h:9, from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/spinlock.h:50, from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/mmzone.h:7, from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/gfp.h:4, from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/kmod.h:22, from /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/module.h:13, from ../my_foo.c:11: > >> /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/thread_info.h:26: error: expected specifier-qualifier-list before 'u32' > >> /home/kris/buildroot-2009.05/toolchain_build_arm_nofpu/linux-2.6.29.4/include/linux/thread_info.h:39: error: expected specifier-qualifier-list before 'u64' > >> > > > > > > Hm, perhaps I should have clarified that this module compiles fine using > > the standard Make approach. (eg. make M=path_to_workspace). > > I'm a bit at a loss why the u32 datatype isn't a problem when using the > > module make... : > > It's when I use Eclipse CDT (Galileo), that the indexer screws up and > > content lost fails, together with compilation error. > > While Googling I've come across threads about bug in Eclipse CDT. > > I'm still trying to resolve this. > > > > I realise this isn't an Eclipse group, but at first I thought the > > problem was in my kernel setup, it isn't. > > Anyone here who found an elegant solution to this CDT problem ? (You > > never know). I don't really know yet if/how the procedure is to debug > > with remote GDB (from within Eclipse) for modules. > > > > I presume Galileo can be tamed to handle Kernel modules.... (?) > > Compiling and debugging from the IDE for "normal" userspace code works > > fine with dynamic or static linked libraries. > > > > I'm trying to get this going because it's possible to learn the kernel > > that much faster again, Galileo's content index brings up all relevant > > structs, macros etc etc. in 1-2-3... > > > > I'm using GCC 4.3.2 on ARM9 cross-target btw. > > > > Thanks in advance for any possible insight or tips ! > > > > -- > > Best regards, > > Kris > > I was sidetracked with other issues, but I resolved this issue in the interim. You're quite right, that was the common denominator (__KERNEL__), but the exact problem ended up being a LOT more tricky than that. Hours of googling didn't help, as there's nothing around specific to cross-compiling. (not that I could find) The solution was that the Eclipse environment itself really goes to lala land about finding executables for module building. I constantly struggled with Make [2] Error 127.... Despite very clear Environment definitions and path definitions, Eclipse wanted absolute paths in the Makefile and over-verbose Target and Cross Compile declarations. A sample/excerpt of my Makefile in case anyone runs into this mess themselves : PWD := $(shell pwd) SAM9_BUILDROOT = /home/kris/buildroot-2009.05 PROJECT_BUILD_ARM = $(wildcard $(SAM9_BUILDROOT)/project_build_arm) BUILD_ARM = $(wildcard $(SAM9_BUILDROOT)/build_arm) CROSS_KERNELDIR = $(PROJECT_BUILD_ARM)/SAM9/linux-2.6.29.4 CROSS_COMPILE = $(BUILD_ARM)/staging_dir/usr/bin/arm-linux- all: kernel-module .PHONY: kernel-module TARGET_ARCH=-Os -march=armv5te -mtune=arm9tdmi -Wa,-mcpu=arm CC = $(CROSS_COMPILE)gcc kernel-module: $(MAKE) -C $(CROSS_KERNELDIR) M=$(PWD) ARCH=arm CROSS_COMPILE= $(CROSS_COMPILE) modules I hope this helps someone else one day. I lost about a day and a half with this issue, but perseverance gets you there :-) My next hurdle now is to figure how to debug using GDB on Kernel Modules. Does anyone have any insight on this ? I can't just start debug on the module, because it hasn't been inserted. I can't just start insmod on the target either, because then the debugger isn't executing the "test" module. I might send a separate post on that to see if anyone has done this before. -- Best regards, Kris -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
