From: David Howells <dhowells@redhat.com>
Fix the extern declaration of kallsyms_num_syms to indicate that the symbol

does not reside in the small-data storage space, and so may not be accessed

relative to the small data base register.
Signed-off-by: David Howells <dhowells@redhat.com>

---
 kernel/kallsyms.c |    3 ++-

 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c

index 474219a..fa84b83 100644

--- a/kernel/kallsyms.c

+++ b/kernel/kallsyms.c

@@ -32,7 +32,8 @@
 /* These will be re-linked against their real values during the second link stage */

 extern const unsigned long kallsyms_addresses[] __attribute__((weak));

-extern const unsigned long kallsyms_num_syms __attribute__((weak));

+extern const unsigned long kallsyms_num_syms

+__nongpreldata __attribute__((weak));

 extern const u8 kallsyms_names[] __attribute__((weak));
 extern const u8 kallsyms_token_table[] __attribute__((weak));
-

On Tue, 06 Nov 2007 21:48:20 +0000
-

Oops.  Well... is there any other CPU?  Apart from MN10300, that is... :-)
I remember I had to fix a bunch of things like this before... I wonder how I

did it...
David
-

Rather than using __nongpreldata, I should be able to say that it's in

.rodata - which seems to be more correct anyway - and throw into a comment to

say why.
I can't quite work out, though, how the kernel build stuff gets the datum into

the kernel build.  I can see there's a script, but I never see the output of

the script crop up anywhere in the build tree:-/  GDB reports, though, that

kallsyms_num_syms gets the right value.
David

-