Date: Thu, 22 Jan 2015 19:05:29 +0000 From: "Sinha, Prokash" <psinha@panasas.com> To: "Sinha, Prokash" <psinha@panasas.com>, Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: elf linking problem Message-ID: <D0E68999.48BB%psinha@panasas.com> In-Reply-To: <D0E66142.4887%psinha@panasas.com> References: <D0E66142.4887%psinha@panasas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks Konstantin,
Yes it looks like MODULE_DEPEND(...) is a must include ...
Here is a quick hack to test the idea .
-prokash
++++
++++ hello_fsm.c
#include <sys/param.h>
#include <sys/module.h>
#include <sys/kernel.h>
#include <sys/systm.h>
void mysymexternfunc( void );
void mysymexternfunc( void )
{
uprintf("mysymexternfunc( ) in hello_fsm.c\n");
}
/* The function called at load/unload. */
static int event_handler(struct module *module, int event, void *arg) {
int e =3D 0; /* Error, 0 for normal return status */
switch (event) {
case MOD_LOAD:
uprintf("Hello Free Software Magazine Readers! \n");
break;
case MOD_UNLOAD:
uprintf("Bye Bye FSM reader, be sure to check
http://freesoftwaremagazine.com !\n");
break;
default:
e =3D EOPNOTSUPP; /* Error, Operation Not Supported */
break;
}
return(e);
}
/* The second argument of DECLARE_MODULE. */
static moduledata_t hello_conf =3D {
"hello_fsm", /* module name */
event_handler, /* event handler */
NULL /* extra data */
};
DECLARE_MODULE(hello_fsm, hello_conf, SI_SUB_DRIVERS, SI_ORDER_MIDDLE);
MODULE_VERSION(hello_fsm, 1);
+++++ end of hello_fsm.c ( this is the only src file is hello_fsm.ko )
OK now check if the hello_fsm.ko got loaded, also check if the function is
defined in the kern.function_list name space
root@mau-elcano-2:~/psinha/kernel # kldstat
Id Refs Address Size Name
1 13 0xffffffff80200000 1755658 kernel
2 1 0xffffffff81a11000 357f ums.ko
3 1 0xffffffff81a15000 43bce linux.ko
4 1 0xffffffff81a59000 755d autofs.ko
5 1 0xffffffff81a61000 1ce hello_fsm.ko <--- so far so good
oot@mau-elcano-2:~/psinha/kernel2 # !342
sysctl -b kern.function_list | tr '\0' '\n' | grep mysymexternfunc
mysymexternfunc <--- okay we found the sum
+++++ Start of hello_fsm2.c ( only file for hello_fsm2.ko )
#include <sys/param.h>
#include <sys/module.h>
#include <sys/kernel.h>
#include <sys/systm.h>
extern void mysymexternfunc( void ); <-------- importing a function
defined and in the kern.function_list
/* The function called at load/unload. */
static int event_handler(struct module *module, int event, void *arg) {
int e =3D 0; /* Error, 0 for normal return status */
switch (event) {
case MOD_LOAD:
mysymexternfunc();
uprintf("Hello Free Software Magazine Readers! \n");
break;
case MOD_UNLOAD:
mysymexternfunc();
uprintf("Bye Bye FSM reader, be sure to check
http://freesoftwaremagazine.com !\n");
break;
default:
e =3D EOPNOTSUPP; /* Error, Operation Not Supported */
break;
}
return(e);
}
/* The second argument of DECLARE_MODULE. */
static moduledata_t hello_conf2=3D {
"hello_fsm2", /* module name */
event_handler, /* event handler */
NULL /* extra data */
};
DECLARE_MODULE(hello_fsm2, hello_conf2, SI_SUB_DRIVERS, SI_ORDER_MIDDLE);
MODULE_DEPEND(hello_fsm2, hello_fsm, 1,1,1); <----- This is to hint the
kernel ( not really needed for manual load !!! )
++++ Try to load module two.
rroot@mau-elcano-2:~/psinha/kernel2 # kldload ./hello_fsm2.ko
mysymexternfunc( ) in hello_fsm.c <---- found the kernel symbol
Hello Free Software Magazine Readers!
root@mau-elcano-2:~/psinha/kernel2 # kldstat
Id Refs Address Size Name
1 15 0xffffffff80200000 1755658 kernel
2 1 0xffffffff81a11000 357f ums.ko
3 1 0xffffffff81a15000 43bce linux.ko
4 1 0xffffffff81a59000 755d autofs.ko
6 2 0xffffffff81a61000 1f6 hello_fsm.ko
7 1 0xffffffff81a62000 1d6 hello_fsm2.ko <---- loaded
On 1/22/15 8:18 AM, "Sinha, Prokash" <psinha@panasas.com> wrote:
>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=A9
>
>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.
>
>_______________________________________________
>freebsd-hackers@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0E68999.48BB%psinha>