From nobody Fri Aug 27 15:29:34 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 5FE60178A371 for ; Fri, 27 Aug 2021 15:29:43 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailsec218.isp.belgacom.be (mailsec218.isp.belgacom.be [195.238.22.114]) (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 4Gx3YL6vv5z3l3j; Fri, 27 Aug 2021 15:29:42 +0000 (UTC) (envelope-from tijl@freebsd.org) IronPort-SDR: 1VmJvCRCcD+HnTI9gxDlzuUyzE2oQOqF/lFxQu/0sVC9HP/ZtK6GgGMXdVGE0zqhcd7WSltIEg rIzLhvctJIQbPYuS+YbhhGvlP+vWe2K+3CWiN0N2bF3NScCDBrMaeW/Q9BPCYomLq4a5VZtvXm 1KOWzcv8/X3x75sO97MWfnUM9H1/GxVA4fznnUOD7P+LWrCq4zWFj02JzNij01ne36ly1LYeHp LvZzExKbmmS5/4LFVJcdZFRi/iWxG/yCjI0DMxRpgs/dqiDa7GwS3JAuYt9ql+eE818kWhLOTA D8M= X-IPAS-Result: =?us-ascii?q?A2AlAACnAylh/wSs8lFaHAEBAQEBAQcBARIBAQQEAQFAC?= =?us-ascii?q?YE8BwEBCwGDDGsBa4RHiCRghWKCJzgBiieRF4F8CwEBAQEBAQEBAUoEAQErh?= =?us-ascii?q?DcKAoIyJjQJDgECBAEBAQEDAgMBAQEBBQEBBgEBAQEBAQUEAYEjhS9GgjUig?= =?us-ascii?q?2wBBSNWEAsOCgICJgICITYGE4VHAzOrBoExgQGEaII5DYEhgSeBECoBjXlDg?= =?us-ascii?q?UtChD4+giCCJIMXgmQEhj2BAoM2vGpeglpbmHOFTUeVWJEkphKQOYZ+ghRNM?= =?us-ascii?q?AiDJFAZD44sFo4wPwMwOAIGAQoBAQMJgkWMVwE?= IronPort-PHdr: A9a23:7u4aXxHZLJ3GTxjT4vLMZZ1Gf/ZMhN3EVzX9CrIZgr5DOp6u447ld BSGo6k31BmQBN6QsaoMotGVmpioYXYH75eFvSJKW713fDhBt/8rmRc9CtWOE0zxIa2iRSU7G MNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1Ifn+FpLPg8it2O2+5YHfbx9ViDagb75+I wu6oRnMvcQKnIVuLbo8xAHUqXVSYeRWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2Q rxeFzQmLns65Nb3uhnZTAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v6 bpgRh31hycdLzM3/mHZhNJtgqxYoh2hqRNwzJLbboyOKPp+Z7nQcc8GSWZdXMtcUTFKDIOmb 4sICuoMJfhWrYz5p1ATsxa+Ag6sBPjxxT9NnHD227Y62PkmHAHa3QwgHdYOvW/UotXvKqgdT /24wrTGwznZaPNWwzj95ZHOfxs8rv6CQah+ftDNyUkzCQzFlFOQpJTrMT6V1+kAsHWW4vdiW O6zlmMqqgF8rDeyy8oiioTHiJwZxk7E+Ch2wIg4O9+1RFN5bNO5E5ZduSWXOYRqTs0sRWxjp SU0yqUetJO4YSQG0ooryhHBZ/CdboSF4AzvWPyeLDp+mXlrYqiwhwyo/kil0uD8U86030tUo SddidnMs2wN1wTU6siaVvtx5keh1iiL1wDU8uxEIlo7la7aK54k3LEwjJ0TvV7fHi/3mkX2i LWaeVkj+uiv8OTofLDmqYWaN49vkA3+Nb4umsOnDeQ5NAgBQXSb9Py/2bH+50H1XrpHguMsn qXEsp3WO94Xq6GhDw9QyIkj6hK/Dzm80NQfmHkKNE5FeBOFj4jtIFzOLur4AumhjFu3izdk2 urKPrr7ApXCNnTDiqvufa5h605Azwo+1d5f54hKBb4fO/3zQVL+uMXEAR8kKQy02fjoCNNh1 o4FV2KPGLGWP73Jvl+T++0jOe6MZJUauDzlMfgq++bujWMlmV8aZaSmwJoXaHWjE/RoOUWWf 2TjjcwaEWgXpAY+S/bqiFKaWz5Je3myR7485i08CI++DofDQZutgKCA3Ce4BZJZeGRGB0uDE XftbYqEWvMMZDiOLc9mlzxXHYSmHqwm0wqyvQnmyrwvBOfQ/TADsoyrgNty/PHSlhs/8RR7C s2c1yeGSGQizU0SQDpj4Ed76Wd6zUyO1KF+mLQMCd1R49tnSAo3H6XwietgBIahCUr6Yt6VR QP+EZ2dCjYrQ4dpq+I= IronPort-HdrOrdr: A9a23:50CXIKuDJi24rl/lW0iKsN5O7skDr9V00zEX/kB9WHVpm62j5r 2TdZEgviMc5wxxZJheo6HnBEDtex/hHN1OkPAs1M6ZLXLbUTKTXftfBOjZskHd8k/FltK1vJ 0IG8JD4bvLYmSS5vyW3ODXKbgdKKTuytHRuQ4L9QYOcekXA5sQiDuRcjzrcXGeszM2YabRva Dsg/Z6mw== X-IronPort-Anti-Spam-Filtered: 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 17:29:35 +0200 Received: from localhost (localhost [127.0.0.1]) by kalimero.tijl.coosemans.org (8.16.1/8.16.1) with ESMTP id 17RFTYtN002639; Fri, 27 Aug 2021 17:29:34 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Fri, 27 Aug 2021 17:29:34 +0200 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Konstantin Belousov Cc: Dimitry Andric , freebsd-current@freebsd.org Subject: Re: i386 kernel modules unusable due to .plt sections Message-ID: <20210827172934.41e3a3f4@FreeBSD.org> In-Reply-To: References: <20210827154130.7a5b141c@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: 4Gx3YL6vv5z3l3j 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 17:24:58 +0300 Konstantin Belousov wrote: > On Fri, Aug 27, 2021 at 03:41:30PM +0200, T=C4=B3l Coosemans wrote: >> 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 -m32= ": >> 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 relocba= se, 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); 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.