Subject: modutils bug? 'if' clause executes incorrectly

From: Cort Dougan <[email-masked]>
Date: Tue, 10 Oct 2000 22:43:17 -0600

I'm finding that in a Linux/MIPS module the test case attached executes the
'if' clause in

if A
  B
else
  C

in the order A, C, B when A is false and correctly (A, B) when A is true.

This is with GCC version egcs-2.90.29 980515 (egcs-1.0.3 release) and
binutils 2.8.1 (with BFD 2.8.1).

The asm in this routine looks good and I can keep the code from failing by
removing the request_irq() and replacing it with something else that
doesn't call into the kernel.  I can't reproduce this in user-code or in
kernel code.

Does anyone have any suggestions?  Perhaps a suggestion for modutils
version?

---

From: Keith Owens <[email-masked]>
Date: Wed, 11 Oct 2000 16:36:00 +1100

On Tue, 10 Oct 2000 22:43:17 -0600, 
>I'm finding that in a Linux/MIPS module the test case attached executes the

Almost certainly nothing to do with modutils, insmod just relocates and
loads the program.  The only possible modutil problems are an
unexpected relocation being emitted by binutils or insmod not handling
a valid relocation correctly.  Compile with -g then do "objdump -rS
object.o".  What does the offending section of code look like,
including the relocations?

---

From: Florian Lohoff <[email-masked]>
Date: Thu, 12 Oct 2000 00:26:19 +0200

> Does anyone have any suggestions?  Perhaps a suggestion for modutils

Please send the resulting asm code - I hear someone whispering
"Branch delay slot".

Flo
-- 
Florian Lohoff		[email-masked]		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

---

From: Cort Dougan <[email-masked]>
Date: Wed, 11 Oct 2000 16:32:42 -0600

} On Tue, Oct 10, 2000 at 10:43:17PM -0600, Cort Dougan wrote:
} 
} > This is with GCC version egcs-2.90.29 980515 (egcs-1.0.3 release) and
} > binutils 2.8.1 (with BFD 2.8.1).
} > 
} > The asm in this routine looks good and I can keep the code from failing by
} > removing the request_irq() and replacing it with something else that
} > doesn't call into the kernel.  I can't reproduce this in user-code or in
} > kernel code.
} > 
} > Does anyone have any suggestions?  Perhaps a suggestion for modutils
} > version?
} 
} I have an idea what's going wrong, maybe it's related to something that
} Brady Brown recently discovered.  Are the object files you are trying to
} load generated by the assembler?  If so, try to do a relocatable link
} on them with ld -r module-out.o module-in.o.

The small test case I have (bug.c) is being built through gcc and that does
shove the output through as.

I did a mips-linux-ld -r -o bug.re.o bug.o and I get the same incorrect
execution.

---

From: Cort Dougan <[email-masked]>
Date: Wed, 11 Oct 2000 16:38:27 -0600

} On Tue, Oct 10, 2000 at 10:43:17PM -0600, Cort Dougan wrote:
} > if A
} >   B
} > else
} >   C
} > 
} > in the order A, C, B when A is false and correctly (A, B) when A is true.
} > 
} > This is with GCC version egcs-2.90.29 980515 (egcs-1.0.3 release) and
} > binutils 2.8.1 (with BFD 2.8.1).
} > 
} > The asm in this routine looks good and I can keep the code from failing by
} > removing the request_irq() and replacing it with something else that
} > doesn't call into the kernel.  I can't reproduce this in user-code or in
} > kernel code.
} > 
} > Does anyone have any suggestions?  Perhaps a suggestion for modutils
} > version?
} 
} Please send the resulting asm code - I hear someone whispering
} "Branch delay slot".

.c and gzip'd .s attached.

Compiled with: mips-linux-gcc -v -G 0 -mno-abicalls -fno-pic -ffixed-8__
-D__KERNEL__ -DMODULE -D_LOOSE_KERNEL_NAMES -O2   -c 
-fomit-frame-pointer -pipe -mcpu=r8000 -mips2 -mlong-calls
-I/sys/linux/include -I/sys/rtlinux/include -I/sys/rtlinux/include/compat
-I/sys/rtlinux/include/posix -Wall -Wstrict-prototypes -g -D__RTL__
-D__KERNEL__ -DMODULE -D_LOOSE_KERNEL_NAMES -O2   -c -o bug.o main/bug.c

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 11 Oct 2000 17:31:17 +0200

> Does anyone have any suggestions?  Perhaps a suggestion for modutils

I have an idea what's going wrong, maybe it's related to something that
Brady Brown recently discovered.  Are the object files you are trying to
load generated by the assembler?  If so, try to do a relocatable link
on them with ld -r module-out.o module-in.o.

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 11 Oct 2000 17:14:49 +0200

Keith,

> including the relocations?

For such occassions I would like to see some debugging functionality in
modutils which allows dumping the relocated disk image as it would be
loaded into the kernel into a disk image which then could be examined
with objdump etc. for potencial problems.

  Ralf

---

From: Keith Owens <[email-masked]>
Date: Thu, 12 Oct 2000 13:25:31 +1100

On Wed, 11 Oct 2000 17:14:49 +0200, 
>with objdump etc. for potencial problems.

By the time insmod has finished with the module, the rest is a binary
blob.  No ELF headers, no symbols, all the sections run together with a
struct module at the start.  I can dump that easily enough but I
question how much use it would be.  Outputing anything more complicated
such as ELF headers and symbols would be a significant addition to
insmod.

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 13 Oct 2000 02:23:50 +0200

> such as ELF headers and symbols would be a significant addition to

The blob is actually already ok and just what I wanted.  You can easily talk
objdump into disassembling that easily.  All that is required in addition
is the base address of the blob as the argument of the --adjust-vma option.

[ralf@lappi ralf]$ mips-linux-objdump -b binary -m mips --adjust-vma 0xc0000000 -D /etc/group | head

/etc/group:     file format binary

No symbols in "/etc/group".
Disassembly of section .data:

00000000c0000000 <.data>:
    c0000000:	726f6f74 	jalx	c1bdbdc8
    c0000004:	3a3a303a 	xori	$s0,$s1,0x3a3a
    c0000008:	726f6f74 	jalx	c1bdbdc8

  Ralf

---

From: Keith Owens <[email-masked]>
Date: Fri, 13 Oct 2000 11:57:44 +1100

On Fri, 13 Oct 2000 02:23:50 +0200, 
>is the base address of the blob as the argument of the --adjust-vma option.

I will add insmod option -O to save the binary object to a file.
  insmod -m -O binary module
will save the binary blob, -m already gives you the section and symbol
map for the final binary object.

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 13 Oct 2000 13:57:31 +0200

Cort,

I think in your module the following jump gets misstreated:

  90:   0800002d        j       b4 <init_module+ac>
                        90: R_MIPS_26   .text

This one is is supposed to skip over the ``printk("A");'' code after
``printk("B");'', so it's the prime suspect.

And this is how current modutils correctly compute such a R_MIPS_26
relocation in obj/obj_mips.c:

      *loc = (*loc & ~0x03ffffff) | ((*loc + (v >> 2)) & 0x03ffffff);

But older modutils - including the modutils-2.1.121-12lm.src.rpm package
from oss - do this:

      *loc = (*loc & ~0x03ffffff) | ((*loc & 0x03ffffff) + (v >> 2));

which is different - and wrong.  This latter expression will for an
assumed load address of 0xc0000000 place 0x3800042d into *loc which
is ``xori $zero, $zero, 0x42d'', in other words a glorified nop resulting
in the printk("A") statement also getting executed.

So the fix should be either upgrading modutils or replacing above
expression in obj/obj_mips.c in your old version of modutils with the
correct one.

  Ralf

---

From: Keith Owens <[email-masked]>
Date: Sat, 14 Oct 2000 02:43:59 +1100

On Fri, 13 Oct 2000 13:57:31 +0200, 
Ralf Baechle <[email-masked]> wrote:
>which is different - and wrong.

Would that be this entry in the change log from 1998?

Tue Nov  3 22:26:18 MET 1998  Ralf Baechle  <[email-masked]>

        * obj/obj_mips.c (arch_apply_relocation): Fix application of R_MIPS_26
        relocations.

Thanks for tracking the problem down.  I really, *really* want to kill
people using modutils 2.1.121 on current kernels.

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 13 Oct 2000 19:40:31 +0200

> people using modutils 2.1.121 on current kernels.

Now that explains the deja vue I had when I found this one ...

I'm not using modules at all which why I still have such vintage modutils
around ...

  Ralf

---

From: Cort Dougan <[email-masked]>
Date: Fri, 13 Oct 2000 13:25:27 -0600

} Now that explains the deja vue I had when I found this one ...
} 
} I'm not using modules at all which why I still have such vintage modutils
} around ...

Can someone send me a fixed version of the BE modutils binary?  I can give
it a try and see if the trouble goes away.