Hi Mulyadi/all, 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.... This ended up being a valuable tip, thanks ! I'd been looking at module.c too much, and missed the do_one_initcall()... I just have a breakpoint at Line 709 ( fn = (initcall_t)...) where the actual initial module code is called. This ended up working great for me, but I ran across something bizarre about mem placement of the module init code : In my particular embedded target, kernel modules always are placed (the 1st time) at 0xbf000000 by vmalloc(). As an example, consider a simple (arbitrary) module header inspection (as per Robert's column, tnx !) : .init.text 0174 .text 0058 .bss 061c .data 04ac Using add-symbol-file, gdb is informed of the sections. The strange thing is that the .init.text section gets placed at 0xBF003000, NOT eg. 0xBF000174 like in example above. I've been trying to figure this out, but can't make ends of it... Does anyone know why .init.text address is placed by vmalloc() at the 0x3000 offset ? Note : removing and re-inserting modules normally happens in increments of 0x3000 (but I guess this depends on module code size...) in an example such as above. IOW, if I remove the module above and then insmod again, it will get placed at 0xBF003000, 0xBF006000,.. etc. - .init.text.address will always be the newly allocated address + the offset where the next insmod would place the module init code... Can anyone shed light on this ???? -- 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
