modules for evbarm (and maybe arm)

[Lloyd Parkes <lloyd%must-have-coffee.gen.nz@localhost>]

After much grovelling in KGDB and objdump, it looks as if the reloc  
in the link_set_modules section of the kmod isn't being processed  
correctly.

I'll walk through kern_module.c:module_fetch_info().

We have a kmod loaded into RAM. The pointer mod->mod_kobj->ko_address  
points to the area just after the ELF header in the kmod (i.e. it  
points to .text).

We call kobj_find_section() and get back addr and size.

On my system I get:
        0xc298a000      mod->mod_kobj->ko_address
        0xc298ef98      addr
        4                       size

objdump tells me that the link_set_modules section (the one we are  
looking for) is at offset 0x4fcc, or 0x4f98 bytes from the header.  
So, addr is pointing at the right place.

The value of *addr is 0xc298ec14, which looks like a kernel address,  
so far so good.

Trouble is, the value should be ko_address + .rodata + 0x370 - .text.  
0x370 is the relocation offset for the module inf, .rodata is the  
section it's in and .text is our base.

        0xc298a000
        + 0x4c48
        + 0x370
        - 0x34
        = 0xc298ef84

So, the relocated contents of link_set_modules is out by 0x370 bytes.

When I look at a binary dump of the link_set_modules sections, I can  
clearly see the value 0x370 in the file. When I run objdump, it  
clearly tells me that we have an absolute relocation to .rodata with  
no offset.

{objdump -r}
        RELOCATION RECORDS FOR [link_set_modules]:
        OFFSET   TYPE              VALUE
        00000000 R_ARM_ABS32       .rodata

{objdump -s}
Contents of section link_set_modules:
 0000 70030000                             p...

Apart from that, all I know is that it's New Year's Eve and I'm  
having a drink.

Cheers,
Lloyd