Hi Mulyadi, On Thu, 2009-08-06 at 01:51 +0700, Mulyadi Santosa wrote: > On 8/6/09, Microbit_Ubuntu <microbit@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > 2. As referred to in the u32 previous post, I'm a bit stumped how to > > invoke GBD on debugging kernel modules. > > Do I need a separate "pre-command" from the debugger, launching > > insmod, or some such ? > > What do you want to debug against your kernel module? decoding oops > message? tracking the code flow? > > Maybe what you need to do is setup virtual environment first e.g using > Qemu. Put your kernel module inside the guest image and run Qemu plus > enable its gdb stub. > > After that, insert your module inside the guest using normal insmod > command. The trick here is, assuming you want to stop at module init > function, how to stop exactly when entering it while its symbol is > still not resolved 'til the moment it is loaded? > > Check the following stack trace: > [278057.822340] [<e02b6018>] hi+0x8/0x44 [mymodule] > [278057.822353] [<c0401152>] do_one_initcall+0x65/0x172 > > "hi" is module_init function ( I steal that from Robert Day's article, > sorry Robert...). So as you can see, put breakpoint in > do_one_initcall(). Once it is hit, it means all the symbols of the > module are resolved already... and for the rest of the work...you know > what to do :) > > Please CMIIW people.... I'm only attempting to track code flow. I've taken some liking to Eclipse's debugger - and its content indexer (giving a great and fast lookup of all symbols and calls involved) This is more an "academic" exercise, because I can see things happening "hands-on", rather than reading - or - just insmodding and seeing the module code execute. I've played with Qemu, but I like "stepping" through my actual target executables. Using SSH/SFTP, the "Remote System Explorer" in Eclipse is a great tool too - I find. I can expand "my processes", "all processes" & their related info and see all information on my target (Linux-wise I mean). I do debug after mounting my target through NFS, so I don't have to 'copy' any code to the target. My target already 'sees' all necessary info by mounting to my host's HDD workspace folder. This works so smooth for user space executables, it'd be great to get it breathing for modules. The big problem here - of course - is to figure out how to get gdb to already 'know' the module's entry address as you describe above (or Robert in his up and coming article) - but without it running yet ! You see, the remote debug starts gdbserver through the SSH connection (I use Ethernet), and then "remote gdb/mi" takes over in starting things properly, including tracking the entry break point (which in my case of course would be the module's init function - but normally 'main' in the remote C application). I've been reading about kgdb et al, but I can't see how that helps me. Also, the gdbstub is already there anyway. The GUI does have a means to get remote gdb/mi to first insmod the module, but that happens _before_ the actual "application" is started (IOW the module's debugger-context code isn't invoked yet when insmodding). So basically, I have no means to first tell remote gdb/mi what the entry address is for the module...... I'm considering trying the "attach to application" debugger option, to see if that yields results... Hmm, perhaps I'm attempting to run when I can't walk properly yet - dunno. The exercise seems sound to me though, it would tremendously speed up the learning process of kernel internals in a practical context. Not to mention its use when I start writing actual driver code. The reason I actually started this whole learning process is to write a driver for SDIO WiFi cards. I spent a lot of time reverse engineering the SDW-820 Spectec SDIO 802.11b card (IPN2128 Procomm MAC based). I wrote my own complete driver (OS-less) for STA, Ad-Hoc + AP operation and I'm contemplating writing an open source Linux driver for it (the MAC parts will have to be object code though :-( ). I figure that, by the time I've written a sound driver for that SDIO WiFi card, I'm surely well on my way to writing driver code on Linux and mastering the kernel a bit more.. :-) PS : As you probably can tell, I'm from a JTAG ARM background :-) My main tool is normally Rowley CrossWorks for ARM... -- 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
