Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

modules for evbarm (and maybe arm)

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.

        + 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.


Home | Main Index | Thread Index | Old Index