Handle R_ALPHA_REFLONG relocation on Alpha (2.6.0-test11)

First off, I'm not positive that this patch is correct or not, but I'd like to pick the brains of people in the know, to find if I'm approaching this in the right way.

I've been unable to use modules on my Alpha with 2.6.0-test*. modprobe (from module-init-tools 0.9.15-pre3) would claim an invalid module format, and the kernel would tell me "Unknown relocation: 1" Relocation 1 on Alpha is R_ALPHA_REFLONG, and sure enough, readelf -r on one of the modules showed many, many uses of it. From looking at arch/alpha/kernel/module.c, it appeared that while R_ALPHA_REFQUAD was handled, R_ALPHA_REFLONG was not. R_ALPHA_REFQUAD's handling looked simple enough, so I made the change which is inlined below.

Is this the proper way to handle this? After making this change, I've been able to use modules without any problems.

@@ -198,6 +198,9 @@
    switch (r_type) {
    case R_ALPHA_NONE:
      break;
+   case R_ALPHA_REFLONG:
+     *(u32 *)location = value;
+     break;
    case R_ALPHA_REFQUAD:
      /* BUG() can produce misaligned relocations. */
      ((u32 *)location)[0] = value;

Nathan Poznick <[email protected]>

"So many times you've given me comfort and forgetfulness." --Frank
Herbert, Dune

Which gcc and binutils versions do you use? I've seen some variation in which relocations they produce.

Måns Rullgård
[email protected]

Thus spake M?ns Rullg?rd:

I'm using gcc 3.3.2 and binutils 2.14.90.0.7. The patch shouldn't hurt when using versions which may produce other relocations, correct? If R_ALPHA_REFLONG isn't generated, then that bit of the switch statement just wouldn't be hit.

Nathan Poznick <[email protected]>

If you write something wrong enough, I'll be glad to make up a new
witticism just for you. -- Larry Wall

Which module? This relocation should never EVER show up in kernel code.

(It will show up in dwarf2 debug info, so make sure you're not looking at objects compiled with -g, but debug sections ought to be ignored by the module loading code.)

r~

Thus spake Richard Henderson:

Well, it was happening on anything I attempted to make a module.

I think that may have been the root cause of this; I had CONFIG_DEBUG_INFO enabled from debugging attempts related to a past problem. With that enabled, -g is used for the compile, so the relocations were added, and module loading failed. After disabling it, R_ALPHA_REFLONG did not appear in any of the object files. So I suppose my next question is if this is a known/intended side effect -- enabling CONFIG_DEBUG_INFO means that modules cannot be used?

Nathan Poznick <[email protected]>

My school colors were clear. We used to say, "I'm not naked, I'm in the
band." -Stephen Wright

No. This means there's a bug in the generic bits of the module loaders, that they're not discarding debugging sections.

r~

Agree with Richard, unless toolchain is setting SHF_ALLOC on those sections for some weird reason.

Nathan, can you mail me (off-list) a module which needs this? I'll take a look.

Thanks,
Rusty.

   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

Ah, my bad. We suck in the whole module, then copy SHF_ALLOC sections, then apply relocations. We don't skip relocations on sections which haven't been copied.

This patch works for me: Nathan, does it solve your problem? Rusty.

   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

Name: Don't Apply Relocations To Sections We Haven't Copied
Author: Rusty Russell
Status: Tested on 2.6.0-bk1

D: The module code applies every relocation section given.  Obviously, if
D: the section has not been copied into the module, there's no point.
D: In particular, Alpha has relocs which are only used on debug sections,
D: so they don't load with CONFIG_DEBUG_INFO enabled.

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .2481-linux-2.6.0-bk1/kernel/module.c .2481-linux-2.6.0-bk1.updated/kernel/module.c
--- .2481-linux-2.6.0-bk1/kernel/module.c	2003-11-24 15:42:33.000000000 +1100
+++ .2481-linux-2.6.0-bk1.updated/kernel/module.c	2003-12-30 14:08:40.000000000 +1100
@@ -1618,9 +1618,13 @@ static struct module *load_module(void _
 	/* Now do relocations. */
 	for (i = 1; i < hdr->e_shnum; i++) {
 		const char *strtab = (char *)sechdrs[strindex].sh_addr;
-		if (sechdrs[i].sh_type == SHT_REL)
-			err = apply_relocate(sechdrs, strtab, symindex, i,mod);
-		else if (sechdrs[i].sh_type == SHT_RELA)
+
+		/* Skip relocations on non-allocated (ie. debug) sections */
+		if (sechdrs[i].sh_type == SHT_REL
+		    && (sechdrs[sechdrs[i].sh_info].sh_flags & SHF_ALLOC))
+			err = apply_relocate(sechdrs, strtab, symindex,i, mod);
+		else if (sechdrs[i].sh_type == SHT_RELA
+			 && (sechdrs[sechdrs[i].sh_info].sh_flags & SHF_ALLOC))
 			err = apply_relocate_add(sechdrs, strtab, symindex, i,
 						 mod);
 		if (err < 0)

Thus spake Rusty Russell:

This did indeed solve my problem on Alpha. I can now use modules with CONFIG_DEBUG_INFO.

Thanks!

Nathan Poznick <[email protected]>

"Time for go to bed." -Tor Johnson. #320