Hi Kris... On Mon, Aug 31, 2009 at 9:38 PM, Microbit_Ubuntu<microbit@xxxxxxxxxxxxxxxxxxxxxx> wrote: > Hi Mulyadi/all, > This ended up being a valuable tip, thanks ! > I'd been looking at module.c too much, and missed the do_one_initcall()... I am glad you find it useful. That was actually a quick research, mixing a fast stack strace analysis and knowing the fact that symbol resolving/relinking is done in insertion stage. So just knowing the point where the point the module is inserted but not yet running is the key here, and stack trace provides us the clear picture instead of doing static code analysis. Again, another thanks to dump_stack(). :) > 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 ???? very wild guess, in your embedded target, the "pad" between vmalloc virtual address range is given such amount so that you are always given starting address of 0x3000 and its multiplication. I forgot the official name of this "pad", but IIRC it works as "shield" between vmalloc area. This area is made non accessible, so every access beyond allocated area for module will cause "oops" or something like that. Perhaps somebody knows better than me, but that's all I can recall right now. -- regards, Mulyadi Santosa Freelance Linux trainer blog: the-hydra.blogspot.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
