Date: Thu, 22 Jan 2015 16:18:56 +0000 From: "Sinha, Prokash" <psinha@panasas.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: elf linking problem Message-ID: <D0E66142.4887%psinha@panasas.com>
next in thread | raw e-mail | index | archive | help
I looked at the MODULE_DEPEND, and it is a hint to the kernel, sort of
load ordering ( in other OS terminology).
Here I'm using kldload first to A module, which loads fine, there is a
kernel variable that is defined in the
Kernel space, that I can verify with -
sysctl -b kern.function_list | tr '\0' '\n' | <the symbol>
Now when I do the kldload of the dependent module B, I see these=8A
By the way, the module loads works fine on freebsd7.2, I tested them.
So I was thinking if new compiler/ld could have something to do with it ?
-prokash
On 1/22/15 2:38 AM, "Konstantin Belousov" <kostikbel@gmail.com> wrote:
>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.
>>=20
>> Would appreciate any insight !
>>=20
>> Thanks,
>> -prokash
>>=20
>> 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
>>=20
>> +++++ The code section -
>>=20
>> 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;
>>=20
>>=20
>>=20
>>=20
>> On 1/16/15 10:43 AM, "Sinha, Prokash" <psinha@panasas.com> wrote:
>>=20
>> >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?D0E66142.4887%psinha>