Date: Thu, 22 Jan 2015 01:34:06 +0000 From: "Sinha, Prokash" <psinha@panasas.com> To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: FW: elf linking problem Message-ID: <D0E592E4.4856%psinha@panasas.com> In-Reply-To: <D0DE9AB7.460A%psinha@panasas.com> References: <D0DDC5CA.45E0%psinha@panasas.com> <D0DE78C0.45F6%psinha@panasas.com> <D0DE9AB7.460A%psinha@panasas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=3D2
linker_load_file: trying to load /boot/kernel/panfs.ko
linker_load_file: error !=3D ENOENT file=3D/boot/kernel/panfs.ko
linker_load_file: Unsupported file type
+++++ The code section -
case R_X86_64_PC32: /* S + A - P */
addr =3D lookup(lf, symidx, 1);
where32 =3D (Elf32_Addr *)where;
val32 =3D (Elf32_Addr)(addr + addend -
(Elf_Addr)where);
if (addr =3D=3D 0){
printf("kldload: R_X86_64_PC32 rtype
switch\n"); <--------- Lookup failure.
return -1;
}
if (*where32 !=3D val32)
*where32 =3D 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 ?
>>>
>>>Thanks,
>>>-prokash
>>>
>>>
>>>_______________________________________________
>>>freebsd-toolchain@freebsd.org mailing list
>>>http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
>>>To unsubscribe, send any mail to
>>>"freebsd-toolchain-unsubscribe@freebsd.org"
>>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0E592E4.4856%psinha>