From nobody Fri Aug 27 15:32:43 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 7839F178DB20 for ; Fri, 27 Aug 2021 15:33:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Gx3d82Yvxz3pBr; Fri, 27 Aug 2021 15:33:00 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82a.google.com with SMTP id 2so1063793qtw.1; Fri, 27 Aug 2021 08:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=EK7UnSmVEaLnGscwDSCmHBkCcV+4HAnAaOReIFjb4CM=; b=GF8IJOiOl+T+/aBYxxHJMp2HXqzLdsgLjN4kuMIJ1muxhrCWlEWhVgrjHtt8235i7M 1fm0TfIwmgaDMxz2eO3JBVhiJa5SCCF6WNYgZEXbng0o70543jSwcuKu5c8U/dZDV2iD jkkZJ70LnkjYbhJqbC9a7bbMdiE1JCnOyFjPkdZ1FkNbzo2zVz2iZ1T6q6YUsRvAyBEo okvFTZv5Ktu+LGXTKznhaui/fI9OEz/POd8h7FfewF2wxPDnLWgZq3aVmNKZohXEBrTA LXnfS0XmWqDqp3Wzg/jajiNR9WJIPX69guhhOYFu9/UeJrVWpDU+xybX4chfLLvOAqrW Leig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=EK7UnSmVEaLnGscwDSCmHBkCcV+4HAnAaOReIFjb4CM=; b=fyTA1Owf+N9qzW5pRGBoiNYng8DH68S1nrHV5gGmcWz7AtDFCJx/75g75FrQXuy9yE n2iZ8E7ncD23affsv6br/Hbwabj340+vKcSAHkjAjX3G8NQ/JQs5MfElQEHDH65b3n0F mRRStxFzFShQTPNdvSp4wFwpn+8TIU7u70Aix7cwiGsfGROup5OoyYxDws+pXOQZo494 bgfDbUSs+Z3J+5DPci4H7vh19ssxsK4OkS2KEi9NWB0AFWWL9aacsB5A1nqUg+JbEkaC wKGZ1ucOi/LUPqKHvd0UqzTZxx6l8cX20B6vCMQN0S4SaJnicbS6VDYT7Ohd72xw1guq 2npA== X-Gm-Message-State: AOAM533QWn+zymRcoFhvt2xANotTunzOtxRKSxzPH+/gXGprrEaLEJQZ iui5bjjChpJJBLzQAaItb+nH4aBQ71At6w== X-Google-Smtp-Source: ABdhPJz3aQCRWcLvbMGI0qUfn/NXgNl2GDYYCko3gegpnLh/QGNs6/gJnu1vkQ36/xiIk0NQDXBN6Q== X-Received: by 2002:a05:622a:1704:: with SMTP id h4mr8695123qtk.9.1630078373896; Fri, 27 Aug 2021 08:32:53 -0700 (PDT) Received: from nuc ([142.126.162.193]) by smtp.gmail.com with ESMTPSA id i19sm4551720qka.53.2021.08.27.08.32.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Aug 2021 08:32:53 -0700 (PDT) Date: Fri, 27 Aug 2021 11:32:43 -0400 From: Mark Johnston To: =?utf-8?Q?T=C4=B3l?= Coosemans Cc: Konstantin Belousov , Dimitry Andric , freebsd-current@freebsd.org Subject: Re: i386 kernel modules unusable due to .plt sections Message-ID: 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210827172934.41e3a3f4@FreeBSD.org> X-Rspamd-Queue-Id: 4Gx3d82Yvxz3pBr 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, Aug 27, 2021 at 05:29:34PM +0200, Tijl Coosemans wrote: > On Fri, 27 Aug 2021 17:24:58 +0300 Konstantin Belousov > wrote: > > On Fri, Aug 27, 2021 at 03:41:30PM +0200, Tijl 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. > >> > >> The following code shows the difference between clang11 and clang12: > >> > >> -------- > >> #include > >> > >> void * > >> test_memset(void *p, int c, size_t len) { > >> return (memset(p, c, len)); > >> } > >> > >> void * > >> test_memcpy(void *dst, const void *src, size_t len) { > >> return (memcpy(dst, src, len)); > >> } > >> > >> void * > >> test_memmove(void *dst, const void *src, size_t len) { > >> return (memmove(dst, src, len)); > >> } > >> -------- > >> > >> 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 > >> > >> 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 > > > > Are you asking (for somebody) to add R_386_JMP_SLOT to i386/elf_machdep.c? > > Like this, not even built. > > > > 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 relocbase, const void *data, > > break; > > > > case R_386_GLOB_DAT: /* S */ > > + case R_386_JMP_SLOT: > > error = lookup(lf, symidx, 1, &addr); > > if (error != 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. Does disabling -zifunc-noplt fix the problem? I believe it's set by default for i386.