Date: Thu, 22 Jan 2015 12:38:29 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: "Sinha, Prokash" <psinha@panasas.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: FW: elf linking problem Message-ID: <20150122103829.GA42409@kib.kiev.ua> In-Reply-To: <D0E592E4.4856%psinha@panasas.com> References: <D0DDC5CA.45E0%psinha@panasas.com> <D0DE78C0.45F6%psinha@panasas.com> <D0DE9AB7.460A%psinha@panasas.com> <D0E592E4.4856%psinha@panasas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150122103829.GA42409>