From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 22 17:52:11 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 27D72F51 for ; Thu, 22 Jan 2015 17:52:11 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0057.outbound.protection.outlook.com [157.56.110.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F2FBBF6 for ; Thu, 22 Jan 2015 17:52:09 +0000 (UTC) Received: from DM2PR0801MB650.namprd08.prod.outlook.com (10.242.127.153) by DM2PR0801MB618.namprd08.prod.outlook.com (10.242.127.146) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 16:18:58 +0000 Received: from DM2PR0801MB652.namprd08.prod.outlook.com (10.242.127.155) by DM2PR0801MB650.namprd08.prod.outlook.com (10.242.127.153) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 16:18:57 +0000 Received: from DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) by DM2PR0801MB652.namprd08.prod.outlook.com ([10.242.127.155]) with mapi id 15.01.0059.007; Thu, 22 Jan 2015 16:18:56 +0000 From: "Sinha, Prokash" To: Konstantin Belousov Subject: Re: elf linking problem Thread-Topic: elf linking problem Thread-Index: AQHQNl8e7oEYrYSqIUWAPLQ9gqdZQw== Date: Thu, 22 Jan 2015 16:18:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.80.217.3] authentication-results: spf=none (sender IP is ) smtp.mailfrom=psinha@panasas.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:DM2PR0801MB650; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB650; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(164054003)(189002)(51704005)(377454003)(24454002)(199003)(77096005)(101416001)(64706001)(54356999)(122556002)(99286002)(36756003)(2656002)(46102003)(68736005)(87936001)(50986999)(62966003)(77156002)(40100003)(106116001)(105586002)(92566002)(2900100001)(102836002)(66066001)(97736003)(110136001)(19580395003)(19580405001)(1411001)(106356001)(86362001)(94096001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB650; H:DM2PR0801MB652.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: panasas.com does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-ID: <68C946CBEAE1974A8105C29265879948@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2015 16:18:56.2515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: acf01c9d-c699-42af-bdbb-44bf582e60b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0801MB650 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB618; X-OriginatorOrg: panasas.com 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 17:52:11 -0000 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' | 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" 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" 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" 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.