On Wed, May 23, 2012 at 10:51 AM, Sarbojit Ganguly
<unixman.linuxboy@xxxxxxxxx> wrote:
> Hello Dave,
>
> I tried to explain this feature (no doubt you have explain it
> perfectly) but he is looking for _how_ kernel module gets loaded and
> somehow (I wonder how!) dubs the entire process as "incremental link"
> !
>
The easiest way to see the whole process happening is to turn on debug,
then modprobe a module. youll see lots of details.
If you build 3.5-rc0 (ie rc1 is not done yet), and turn on CONFIG_DYNAMIC_DEBUG,
you can enable the pr_debugs selectively, and narrow down to the info
that you want.
heres some of the info youll see:
jimc@jimc-desktop:~/projects/lx/linux-2.6$ grep pr_debug kernel/module.c
pr_debug("Failed to find symbol %s\n", name);
pr_debug("%s uses %s!\n", a->name, b->name);
pr_debug("%s does not use %s!\n", a->name, b->name);
pr_debug("Allocating new usage for %s.\n", a->name);
pr_debug("%s unusing %s\n", mod->name, i->name);
pr_debug("Looking at refcount...\n");
pr_debug("%s already dying\n", mod->name);
pr_debug("Found checksum %lX vs module %lX\n",
pr_debug("Common symbol: %s\n", name);
pr_debug("Absolute symbol: 0x%08lx\n",
pr_debug("Core section allocation order:\n");
pr_debug("\t%s\n", sname);
pr_debug("Init section allocation order:\n");
pr_debug("\t%s\n", sname);
pr_debug("\t%s\n", info->secstrings + symsect->sh_name);
pr_debug("\t%s\n", info->secstrings + strsect->sh_name);
pr_debug("final section addresses:\n");
pr_debug("\t0x%lx %s\n",
pr_debug("load_module: umod=%p, len=%lu, uargs=%p\n",
I dont recall if it gets into symbol-by-symbol linking, but it might.
Read Doc/dynamic_debug_howto for more usage info.
Daves simple example would be valuable to look at,
esp with readelf and objdump.
> On 23 May 2012 21:47, Dave Hylands <dhylands@xxxxxxxxx> wrote:
>> Hi Somanath,
>>
>> On Tue, May 22, 2012 at 2:56 AM, somanath sahoo <bapi_mvit2004@xxxxxxxxx> wrote:
>>> Hi,
>>>
>>> As newbie in linux kernel, I would like to understand the concept of
>>> "incremental linking " w.r.t to linux kernel module.
>>
>> Incremental linking is basically just taking some objects files,
>> linking them together to produce a larger object file. The object file
>> still has undefined references. It will also coalesce sections of the
>> same name. The kernel likes to use sections for storing pointers to
>> initcall functions and other things like that.
>>
>> Some people might also call this partial linking. The kernel uses this
>> technique for the main portion of the kernel as well. If you look
>> through your build directory, you will find a whole bunch of
>> built-in.o files. Each one of these is a partially linked object file
>> containing all of the object files from the current directory and
>> built-in.o files from directories below.
>>
>> With kernel modules, there are some special automatically generated C
>> files which also get linked in (IIRC that have a name like foo.mod.c)
>>
>> A kernel module is conceptually identical to a shared library (which
>> is also partially linked and may contain unresolved references).
>>
>> You can do incremental linking by doing:
>>
>> echo "int foo1(void) { return 1; }" > foo1.c
>> echo "int foo2(void) { return 2; }" > foo2.c
>> gcc -c foo1.c
>> gcc -c foo2.c
>> ld -r -o foo.o foo1.o foo2.o
>>
>> You'll now have foo.o which has both foo1.o and foo2.o partially
>> linked together, which you can see by using:
>>
>> nm foo.o
>>
>> --
>> Dave Hylands
>> Shuswap, BC, Canada
>> http://www.davehylands.com
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies@xxxxxxxxxxxxxxxxx
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
