Subject: problems with insmod ...

From: Jun Sun <[email-masked]>
Date: Fri, 20 Oct 2000 19:50:03 -0700

I am using modutils v2.1.121, generated by binutils 2.8.1/egcs
v1.0.3a/glibc 2.0.6.

I have several problems with it.

In obj/obj_mipsel.c arch_apply_relocation() function, the mips_hi16_list
is not initialized to NULL before it is used as a list head.  So, later,
insmod dies at trying to access 0x41.

(BTW, it seems horrible to me that arch_apply_relocation() remaps
obj_file struct to a local mips_file struct, destroying the original ELF
header struct.  Is this safe?)

I kind of hacked around this problem (I don't know the real fix), but I
got some other problems.  This time it is at obj/obj_reloc.c:410 -
sec->contents is 0x0.  It seems to me that this section should be
included in load list at the first place.  Does somebody why it is
there?  

I dumped the section info here :

(gdb) p/x *f->load_order->load_next->load_next
$22 = {
  header = {
    sh_name = 0x36,
    sh_type = 0x70000006,
    sh_flags = 0x2,
    sh_addr = 0xc00000e0,
    sh_offset = 0xd0,
    sh_size = 0x18,
    sh_link = 0x0,
    sh_info = 0x0,
    sh_addralign = 0x4,
    sh_entsize = 0x1
  },
  name = 0x1001bf26,
  contents = 0x0,
  load_next = 0x1001bd88,
  idx = 0x5
}

=======

BTW, I seem to remember someone said the modutils 2.1.121 is not good
MIPS.  Which version is good?

Jun

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 21 Oct 2000 05:11:09 +0200

> (gdb) p/x *f->load_order->load_next->load_next

This is a .reginfo section.  MIPS specific and guaranteed to be useless.
The ABI says we should load it but they're useless, so inside the kernel
simply ignore it.

> MIPS.  Which version is good?

There are patched versions of 2.1.121 available which are usable.  I've
uploaded source and binaries of 2.1.131 and Keith Owen's latest version
into oss.sgi.com:/pub/linux/mips/modutils.

  Ralf

---

From: Keith Owens <[email-masked]>
Date: Sat, 21 Oct 2000 15:12:19 +1100

On Fri, 20 Oct 2000 19:50:03 -0700, 
>MIPS.  Which version is good?

2.1.121 is over two years old and is missing several mips patches.
There is no good reason to use 2.1.121, modutils 2.3 is backwards
compatible.

The last mips specific patch was in modutils 2.3.15.  2.3.18 ignores
empty relocate sections which I believe were a problem for several
architectures, possibly including mips.  2.3.19 will be released this
weekend and includes a mips patch to fix a minor problem which I doubt
anybody has ever hit.  If you need modutils now, use 2.3.18, if you can
wait 48 hours, wait for 2.3.19.

ftp://ftp.<country>.kernel.org/pub/linux/kernel/utils/modutils/v2.3.

---

From: Jun Sun <[email-masked]>
Date: Mon, 23 Oct 2000 11:45:22 -0700

> ftp://ftp.<country>.kernel.org/pub/linux/kernel/utils/modutils/v2.3.

I tried with 2.3.19, and now I am having problem with out of bound index
in symbol table.  See the output below.

---------
sh-2.03# insmod hello.o
hello.o: local symbol gcc2_compiled. with index 10 exceeds
local_symtab_size 10
hello.o: local symbol __gnu_compiled_c with index 11 exceeds
local_symtab_size 10
hello.o: local symbol __module_kernel_version with index 12 exceeds
local_symtab_size 10
---------

I took a look.  It appears that there is bug fix in v2.3.19 that checks
the symbol index against the table size, which in turn discovers this
bug.  

Is this a ld bug?  The sh_info field is indeed 10, but there are more
symbols.

I included the symbol table below, and the command line that I generate
the module.

----------
SYMBOL TABLE:
00000000 l    d  .modinfo       00000000 
00000000 l    d  .rodata        00000000 
00000000 l    d  .text  00000000 
00000000 l    d  .data  00000000 
00000000 l    d  .bss   00000000 
00000000 l    d  *ABS*  00000000 
00000000 l    d  *ABS*  00000000 
00000000 l    d  .note  00000000 
00000000 l    d  .comment       00000000 
00000000 l       .text  00000000 gcc2_compiled.
00000000 l       .text  00000000 __gnu_compiled_c
00000000 l     O .modinfo       0000001b __module_kernel_version
00000000 g     F .text  00000048 init_module
00000000       O *UND*  00000000 printk
00000048 g     F .text  00000040 cleanup_module
-----------

Make command:

mips_5000_le-gcc -Wall -DMODULE -D__KERNEL__ -DLINUX -fno-pic -c hello.c

Jun

---

From: Keith Owens <[email-masked]>
Date: Tue, 24 Oct 2000 09:32:03 +1100

On Mon, 23 Oct 2000 11:45:22 -0700, 
>hello.o: local symbol __gnu_compiled_c with index 11 exceeds

It is a toolchain bug, I think it is in the assembler.  I have a dim
distant memory from about a month ago that somebody on linux-mips found
the problem.  Ask the toolchain experts.

---

From: Brady Brown <[email-masked]>
Date: Mon, 23 Oct 2000 16:42:34 -0600

> I included the symbol table below, and the command line that I generate

There is a known issue right now with the .elf format generated by the mips
assembler. The assembler has the local symbol table ordering and size field
out of sync, consequently when insmod tries to install it, it fails because
there are more local symbols in the file than the 'inf' field in the file
header indicates. I think this is being looked into. As a 'dirty' work
around - the linker does appear to generate correct elf outputs so I am
currently linking all of my modules using the -r command line switch so the
output remains re-locatable. The readelf utility shows the symbol table
stuff if you are interested.  After the incremental link the files insmod's
fine.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brady Brown ([email-masked])       Work:(801)619-6103
Texas Instruments: Broadband Access Group
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 24 Oct 2000 02:40:40 +0200

> the problem.  Ask the toolchain experts.

It's a bug bug in ld, one in BFD and a sillyness in IRIX ELF which the linker
uses.  IRIX ELF uses different sorting rules for the symbol table, see
mips_elf_sym_is_global in bfd/elf32-mips.c.

 - Bug one: ld generated output should follow the same rules as assembler
   generated output.
 - Bug two is more a design flaw - why does Linux/MIPS and most other
   MIPS ELF configurations use IRIX and not ABI ELF?
 - Bug three is that mips_elf_sym_is_global applies these IRIX ELF sorting
   rules even to ABI ELF.

  Ralf

---

From: Jun Sun <[email-masked]>
Date: Mon, 23 Oct 2000 18:08:35 -0700

>  - Bug three is that mips_elf_sym_is_global applies these IRIX ELF sorting

This sounds like a serious problem to me.  So here are the questions : 

1) is it fixed in the latest binutils?
2) is it worth fixed for binutil v2.8.1?

I might be able to fix this problem, but I surely need some fill-ins.

Jun

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 24 Oct 2000 03:18:28 +0200

> 1) is it fixed in the latest binutils?

No, all binutils ever are affected.

> 2) is it worth fixed for binutil v2.8.1?

Probably not.  I believe modulo some testing current CVS binutils are ready
for more serious use than just binutils fixing.  In any case fixing should
be easy.

  Ralf