On Fri, 10 Dec 2010, Mulyadi Santosa wrote:
> Excuse me for any possible stupidity in the following answers :D
>
> On Fri, Dec 10, 2010 at 21:16, Robert P. J. Day <rpjday@xxxxxxxxxxxxxx> wrote:
> > On Fri, 10 Dec 2010, Hemanth Kumar wrote:
> >> I am getting the error unresolved symbol rday_3, ARCH=arm omap kernel=2.3.32.9
> >>
> >> insmod m2.ko
> >> then
> >> insmod m3.ko
> >> unresolved symbol rday_3
>
> IMO the order is right..
so far, so good.
> >> then i did cat /proc/kallsyms | grep rday_3
> >> i can see the rday_3 in that file,But still I am unable to insmod the m3.ko
>
> The address you gave....if I apply 3:1 VM split just like x86..means
> it's out of kernel address space. So, could you confirm what VM split
> your current kernel use?
but how could that cause a problem? surely that would cause
problems with *all* module loading, not just my simple example.
> >> kernel,Below is the code
> >>
> >> file m2.c
> >>
> >> #include <linux/module.h>
> >> #include <linux/init.h>
> >> #include <linux/kernel.h>
> >> static int rday_1 = 1;
> >> int rday_2 = 2;
> >> int rday_3 = 3;
> >> EXPORT_SYMBOL(rday_3);
>
> what if we use EXPORT_SYMBOL_GPL()? And what I am afraid is that all
> those symbol are wiped out due to optimization.
i considered that for a second but if the symbol was wiped out, why
is it still showing up in the /proc/kallsyms file?
a simple test i would make is to remove that "extern" reference from
the second test module and make sure it loads properly. that would at
least isolate the bug to that single extern reference.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
