FW: elf linking problem

[Konstantin Belousov]

On Thu, Jan 22, 2015 at 01:34:06AM +0000, Sinha, Prokash wrote:
> I'm forwarding to the kernel group, in case someone can point me to the
> root of this problem.
> 
> Would appreciate any insight !
> 
> Thanks,
> -prokash
> 
> kldload: R_X86_64_PC32 retype switch  <--- This is the first failure  (
> from dmesg )
> ink_elf_obj: symbol pan_sys_once undefinedELF_RELOC_RELA
> ink_elf_load_file(...) -external relocation error=2
> linker_load_file: trying to load /boot/kernel/panfs.ko
> linker_load_file: error != ENOENT file=/boot/kernel/panfs.ko
> linker_load_file: Unsupported file type
> 
> +++++ The code section -
> 
>   case R_X86_64_PC32: /* S + A - P */
>                         addr = lookup(lf, symidx, 1);
>                         where32 = (Elf32_Addr *)where;
>                         val32 = (Elf32_Addr)(addr + addend -
> (Elf_Addr)where);
>                         if (addr == 0){
>                                 printf("kldload: R_X86_64_PC32 rtype
> switch\n"); <--------- Lookup failure.
>                                 return -1;
>                         }
>                         if (*where32 != val32)
>                                 *where32 = val32;
>                         break;
> 
> 
> 
> 
> On 1/16/15 10:43 AM, "Sinha, Prokash" <psinha at panasas.com> wrote:
> 
> >So what I'm looking for is that if some sums are defined in the kernel
> >namespace by some kernel component, it should be visible by other kernel
> >module at load time fix/resolve those references, which is what the gcc on
> >freebsd 7.2 seem to be doing. For freebsd 10.1 using the clang front, this
> >could be broken.
> >
> >Can anyone point me to some document along the line of freebsd ko
> >linking/loading.
> >
> >I used objdump, but I'm particularly looking for some internals related
> >document, so that I can see the linker actually trying to pull in and
> >fix/resolve ref from the kernel name space.
> >
> >Thanks,
> >-prokash
> >
> >On 1/16/15 8:15 AM, "Sinha, Prokash" <psinha at panasas.com> wrote:
> >
> >>Has anyone seen this , when clang is being used for 10.1 compilation ?
> >>
> >>Thanks,
> >>-prokash
> >>
> >>
> >>On 1/15/15 7:30 PM, "Sinha, Prokash" <psinha at panasas.com> wrote:
> >>
> >>>Hello,
> >>>
> >>>I'm trying to find out what could be the cause of a kldload problem I'm
> >>>facing. Here is the context detail --
> >>>
> >>>
> >>>1. I'm building two ko module. And it has a dependency order, so when I
> >>>load the first module, it loads, and a function symbol ( F ) is defined
> >>>into kernel variable space sysctl -b kern.function_list | tr '\0' '\n' |
> >>>grep symname.
> >>>2. Now trying to load the 2nd module, and link_elf_obj flags error and
> >>>symbol undefined when freebsd10.1 is being used.
> >>>3. If I probe using the same sysctl as in step 1, I still the symbol is
> >>>defined.
> >>>
> >>>/var/log/messages shows -
> >>>kernel: link_elf_obj: symbol pan_sys_once undefined
> >>>kernel: linker_load_file: Unsupported file type
> >>>
> >>>The same two modules when complied using freebsd7.2, we don't see the
> >>>problem.
> >>>
> >>>
> >>>The question is - Is there changes along the elf formats ( in both case
> >>>it
> >>>64bit), also is there any changes
> >>>In the API between those two OS version, that I need to aware of ( and
> >>>possible flags I need to set).
> >>>
> >>>Using objdump -t  modone.ko
> >>>00000000000fb940 g     F .text	0000000000000062 pan_sys_once
> >>>
> >>>
> >>>
> >>>In modtwo.ko it is undefined
> >>>0000000000000000         *UND*	0000000000000000 pan_sys_once
> >>>
> >>>
> >>>Note the objdump on freebsd 7.2, is identical. So it is defined in the
> >>>module1 as F(function), and undefined(UND) in module two.
> >>>
> >>>Any suggestion, please ?

This is unrelated to either compiler version, or ELF format.

If module B depends on the symbol from a module A, the dependency
must be declared with the MODULE_DEPEND() macro.  Look for examples
in the tree to see how to use it.

Main kernel symbols are always visible to the loadable modules.