On Tue, Sep 1, 2009 at 6:37 AM, Microbit_Ubuntu <microbit@xxxxxxxxxxxxxxxxxxxxxx> wrote: > Hi Mulyadi, > > On Tue, 2009-09-01 at 01:44 +0700, Mulyadi Santosa wrote: >> 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. >> > > Oh, perhaps I should have noted that the consecutive module placements are 0x3000 > when my test module doesn't use __init... look into layout_sections() and load_module() in http://lxr.linux.no/#linux+v2.6.30.5/kernel/module.c#L1649 u can see the init sections always comes after other core sections. the virtual memory address are subsequently only derived after all other sections have taken the virtual address. and remember all the sections are always allocated and aligned along PAGE_SIZE alignment (for pagefault reason). > Else - of course - the consecutive placements are 0x6000, but I guess that was implied :-) > > It's still a strange ranger scenario, the init code being placed where - normally - the next insmod > would go. Perhaps the init code is padded as well for some sort of protection... dunno. > > I'll keep the padding issue in the back of my head as I learn further with Linux. I haven't enabled > debug VM in kernel config yet - that's for later.. :-) > > But thanks for the advice and review ! > > -- > 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 > > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
