why not use KDB which has merged into linux kernel? BRs Lin 2009/8/6 Microbit_Ubuntu <microbit@xxxxxxxxxxxxxxxxxxxxxx>: > 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 > > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ