From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 10:38:35 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC1AF23A for ; Thu, 22 Jan 2015 10:38:35 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 54485CFC for ; Thu, 22 Jan 2015 10:38:35 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t0MAcTSC097331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 12:38:29 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0MAcTSC097331 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0MAcTxD097328; Thu, 22 Jan 2015 12:38:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 Jan 2015 12:38:29 +0200 From: Konstantin Belousov To: "Sinha, Prokash" Subject: Re: FW: elf linking problem Message-ID: <20150122103829.GA42409@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 10:38:35 -0000 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" 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" 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" 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.