From nobody Fri Aug 27 16:10:24 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 587281782A78 for ; Fri, 27 Aug 2021 16:10:33 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailsec117.isp.belgacom.be (mailsec117.isp.belgacom.be [195.238.20.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign RSA OV SSL CA 2018" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gx4SS5nFCz4b0b; Fri, 27 Aug 2021 16:10:32 +0000 (UTC) (envelope-from tijl@freebsd.org) IronPort-SDR: szIQCz6Lutc1adW95PTfdBo4uGCmoCx3R7YCSl5KEzGrNGd/Lu2XKwX8rLYAn3DtAKj0zWD94M nf75QaEYqXP1MFgRZOpGVB1MJ03+xdUOT4CYKALXDbpubOvA3JN4ynHThUYK2VHuX/qSwYGZQP vhME26uMZhyLpQc+EXmiNUQfGHeIfrJjybxNk/FhrmdKrUjJZaNEk1jsurrNpI4Q7omuP4W919 JJ4CREDxXXbBZCg6LOW0LRCZ5UVVfUx1lWawoQ6LpMjAmB5gQ2E2Dld7ff6oEcNlOA5BcBqzZ5 haI= X-IPAS-Result: =?us-ascii?q?A2ADAABvDSlh/wSs8lFaGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQAmBPAUBAQEBCwGDDBVWAVEahEeIJGCFYoIkAzgBiieRF4F8C?= =?us-ascii?q?wEBAQEBAQEBATYUBAEBK4Q3CgKCMiY0CQ4BAgQBAQEBAwIDAQEBAQUBAQYBA?= =?us-ascii?q?QEBAQEFBAGBI4UvOQ2CNSkBg2QBBSNWEAsYAgImAgIhNgYTgnKCVQMzqwGBM?= =?us-ascii?q?YEBhyENgSGBJ4EQKgGNeUOBS0KEPj6BUk6CJIMXgmQEhj2BAoIEOXmUOqZ7g?= =?us-ascii?q?TVeglpbikCOM4VNR4UtkCuRJKYSkDmGfoIUfQiDJAlHGQ+OLBaHb4ZBPwMwO?= =?us-ascii?q?AIGAQoBAQMJgkWMVgEB?= IronPort-PHdr: A9a23:gQR+fhOOapfT4TPzHXQl6nZCChdPi9zP1u491JMrhvp0f7i5+Ny6Z QqDv60r1QaSFt+Do9t/yMPu+5j6XmIB5ZvT+FsjS7drEyE/tMMNggY7C9SEA0CoZNTjbig9A dgQHAQ9pyLzPkdaAtvxaEPPqXOu8zESBg//NQ1oLejpB4Lelcu62/6u95HJfglEmTSwbbxsI BmqsA7cqtQYjYx+J6gr1xDHuGFIe+NYxWNpIVKcgRPx7dqu8ZBg7ipdpesv+9ZPXqvmcas4S 6dYDCk9PGAu+MLrrxjDQhCR6XYaT24bjwBHAwnB7BH9Q5fxri73vfdz1SWGIcH7S60/VC+85 Kl3VhDnlCYHNyY48G7JjMxwkLlbqw+lqxBm3oLYfJ2ZOP94c6jAf90VWHBBU95fWSJBHI2yc ogBAOgPPelXs4bzqEADrQenBQS2GO/j1iNEi33w0KYn0+ohCwbG3Ak4EtwQtXbUqMj+ObkVU eCy16nH0zDDYOlQ2Tfm9YPFdQwhofCOXbJ0asffyVMvGB3bgViNtILrMSmZ1uMXs2iU9udtU /+khGE7pQ9ruDev2tsshZfThoIT0l3K9SF0zYQ7K9C4VkJ3f9GqHYZNuiyaK4d7X8EvT39nt Sg6yrMLpZ22cSoOxZknxRPSZeKKfoyJ7x/9WuidPyl1iXR4c7yxgBay9FKvyuz6VsSsyFZKt DRKnsPJtnAO0RHY98uJSuNl80qixDqDzR7f5+5aLUwuiKbWKYAtzqQ/m5cVrE/NBDX5mF/sg 6+Tbkgk/++o5Pn5bbj+vZ+cMpN0ihn5MqQzhsyzGeQ4PRYKX2ic4em816fs/Un4QLVPkPI2i K7ZvIrGJcQapK65BxVZ3Zok6xa4FDepztEYkmMBLFJeYh6HiJLpO17WLPD5C/ewnUisnS9oy vzbJLHtHJrAImbZnLv8f7tx9VRQxQUrwdBa/Z1UC7UBIPzpWk/2sdzVFgM5Mw22w+bjE9h92 JkeVnyRDaCCK6PdrEWE5uU1I+mDfIMVoiryK+A55/7yin80gVEdfbO30pQJc3+4BelpL1yFb nrxmNcBC3kFvgwiTOHxhl2CSyBcaGipUKIn+z43EoWmDZ3MRoq1mryOwD+7HoFKZmBBEl2DD Hbod4CfVvcCciKdPNFunScfVbe8UYMh0guutADiwbp9MuXU4jEYtY7k1NVt5O3Tkgoy9SB1D 8SeyG6CUWV0k3gHRz8zxq9/oEh9xk2f3qh/hvxSDcZT6O9RUgcmKZ7cyPR3C9XoVQLbfdeJS k2rQtu8AT4vUN0+2MQObFtnF9WllBDD0HniP7hAsrWRB9QW9aLaxGT2IY4pzn/c16sJgUMrT 8FUOSuhnKEppCbJAIucr6Kd342tcr8R2SfL7y/X0WuMuGl2SgN9e57pG3cFaR2F/pzC+kreQ ur2WvwcOQxbxJvHc/MSAuA= IronPort-HdrOrdr: A9a23:7jFqaq8n03k7a7UA+g9uk+DVI+orL9Y04lQ7vn2ZKCYlFvBw8v rEoB1173HJYVoqNU3I4OrhBEDiewK4yXcW2+Ms1N6ZNWHbUQ2TTb2KhrGM/9SPIUHDHug079 YDT0B7YOeAbmRHsQ== X-IronPort-Anti-Spam-Filtered: true X-ProximusIPWarmup: true Received: from 4.172-242-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.242.172.4]) by relay.proximus.be with ESMTP; 27 Aug 2021 18:10:25 +0200 Received: from localhost (localhost [127.0.0.1]) by kalimero.tijl.coosemans.org (8.16.1/8.16.1) with ESMTP id 17RGAO4f002752; Fri, 27 Aug 2021 18:10:25 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Fri, 27 Aug 2021 18:10:24 +0200 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Mark Johnston Cc: Konstantin Belousov , Dimitry Andric , freebsd-current@freebsd.org Subject: Re: i386 kernel modules unusable due to .plt sections Message-ID: <20210827181024.06f26328@FreeBSD.org> In-Reply-To: References: <20210827154130.7a5b141c@FreeBSD.org> <20210827172934.41e3a3f4@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Gx4SS5nFCz4b0b X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, 27 Aug 2021 11:32:43 -0400 Mark Johnston wrote: > On Fri, Aug 27, 2021 at 05:29:34PM +0200, T=C4=B3l Coosemans wrote: >> On Fri, 27 Aug 2021 17:24:58 +0300 Konstantin Belousov >> wrote: =20 >>> On Fri, Aug 27, 2021 at 03:41:30PM +0200, T=C4=B3l Coosemans wrote: =20 >>>> I use devel/llvm* to build base and just switched to llvm12. It seems >>>> that on i386 clang12 uses R_386_PLT32 relocations for some calls to at >>>> least memset, memcpy and __stack_chk_fail (clang11 uses R_386_PC32). >>>> These are converted to R_386_JMP_SLOT relocations by the linker which >>>> aren't supported by the kernel, e.g. loading linux.ko gives "kldload: >>>> unexpected relocation type" from sys/i386/i386/elf_machdep.c. The PLT >>>> entries also depend on a base pointer in %ebx but kernel modules aren't >>>> compiled with -fPIC, so this can't work and I suspect this is a >>>> regression in clang12. >>>>=20 >>>> The following code shows the difference between clang11 and clang12: >>>>=20 >>>> -------- >>>> #include >>>>=20 >>>> void * >>>> test_memset(void *p, int c, size_t len) { >>>> return (memset(p, c, len)); >>>> } >>>>=20 >>>> void * >>>> test_memcpy(void *dst, const void *src, size_t len) { >>>> return (memcpy(dst, src, len)); >>>> } >>>>=20 >>>> void * >>>> test_memmove(void *dst, const void *src, size_t len) { >>>> return (memmove(dst, src, len)); >>>> } >>>> -------- >>>>=20 >>>> Output of "readelf -r test.o" when compiled with "clang12 -c test.c -m= 32": >>>> r_offset r_info r_type st_value st_name >>>> 0000002c 00000504 R_386_PLT32 00000000 memset >>>> 00000067 00000304 R_386_PLT32 00000000 memcpy >>>> 000000a7 00000402 R_386_PC32 00000000 memmove >>>>=20 >>>> With clang11: >>>> r_offset r_info r_type st_value st_name >>>> 00000036 00000502 R_386_PC32 00000000 memset >>>> 00000083 00000302 R_386_PC32 00000000 memcpy >>>> 000000d2 00000402 R_386_PC32 00000000 memmove =20 >>>=20 >>> Are you asking (for somebody) to add R_386_JMP_SLOT to i386/elf_machdep= .c? >>> Like this, not even built. >>>=20 >>> diff --git a/sys/i386/i386/elf_machdep.c b/sys/i386/i386/elf_machdep.c >>> index 3754b36d9e33..a26a4189e0ee 100644 >>> --- a/sys/i386/i386/elf_machdep.c >>> +++ b/sys/i386/i386/elf_machdep.c >>> @@ -245,6 +245,7 @@ elf_reloc_internal(linker_file_t lf, Elf_Addr reloc= base, const void *data, >>> break; >>> =20 >>> case R_386_GLOB_DAT: /* S */ >>> + case R_386_JMP_SLOT: >>> error =3D lookup(lf, symidx, 1, &addr); >>> if (error !=3D 0) >>> return (-1); =20 >>=20 >> No, I've tried that. It handles the relocation but callers still don't >> setup %ebx as PIC register. I'm looking for someone to confirm it's a >> compiler bug and not a missing flag or something. I tried -fno-plt and >> that has no effect. =20 >=20 > Does disabling -zifunc-noplt fix the problem? I believe it's set by > default for i386. Removing it from sys/conf/kern.pre.mk didn't help.