Received: by 10.213.65.68 with SMTP id h4csp1133177imn; Wed, 14 Mar 2018 10:32:05 -0700 (PDT) X-Google-Smtp-Source: AG47ELuiuP96pHiTOkR2KROKNxuIdtM5MqkoOiderftigG6uUwFLIEi5MyZJ/K1iADkKmcpwyCzN X-Received: by 10.98.204.132 with SMTP id j4mr5104778pfk.35.1521048725150; Wed, 14 Mar 2018 10:32:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521048725; cv=none; d=google.com; s=arc-20160816; b=AuPtLriUMv53AXqF4TWflhMZVMhYyeGVA86CqYlNmIVuJmhKcSXXAqrSVp0WlbR7Bb OBgUwCUT4W5KNqkS6ZT3uhheUwMUU/chSS7z/9DEkcUoO1hyec+QNBhZPceUbjndxoqH N0nzU5PLIyP5aSgSQKSy+sRHJc/t+WOTz6Qk51D8SruEfRQHeWn7WG/K0Ol8TiaGhAVK VUWdRgjM/a0Prrb9p1Pv3+lsFrBMW8WDm1MoCPtbtrx1b2P6S7C5hVAxOrULTT8hXu2E 8n7KpRmnFUO44RiZ4wYj290kn0ohSBEjOMclkn5IahUtxm1LtezPQ1ZtKGpQFH9I/Ion HnSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature :arc-authentication-results; bh=jivGlEn+GA5P/RTObPxVrK3HwT0JxMFF7S9csrWrQvk=; b=XBkGrk59jM3VXLVd8QPHj9UPUsciWF6F+CorsRG412HhHdn5hs5d4y77qowVs0KOz4 RUOcH1GhFU41kdSa3bJw0ElR89UtCdpEcTOSpvTXx/ROAwVYV6rEpPpE9EpE1/auO5MI omN3sQcH+oMXVT6PwapsFQiHZDhQe8EY0NsK5faoDX17enVoZ8Vd+qKdrZSj39Ux5aJN 7IcvJqdKhF6int35hnnKnSPDJGdLqN4TA6I8OdkXQ7QdOykcQid98IYLdZXcL6PPKU6b vr33+bCYvO9MSMcJn3CZgLI16jqVp2ILsM5CSZptuRA1GrAFL0jmSIyFQkjdq1r0CPCr 7yXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=gphcPcGG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d6-v6si2276019plm.88.2018.03.14.10.31.50; Wed, 14 Mar 2018 10:32:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=gphcPcGG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751456AbeCNRaq (ORCPT + 99 others); Wed, 14 Mar 2018 13:30:46 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:46748 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751131AbeCNRap (ORCPT ); Wed, 14 Mar 2018 13:30:45 -0400 Received: by mail-pf0-f194.google.com with SMTP id z10so1690358pfh.13 for ; Wed, 14 Mar 2018 10:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=jivGlEn+GA5P/RTObPxVrK3HwT0JxMFF7S9csrWrQvk=; b=gphcPcGGNTx0rtz4EA2W8b/zL2NOOmBvkilMI+5MzUPYf2Xuxg94eYO0TS0ZjOzkrV j0v9mjEUqQ41ijR3MkWe8c1KrHrjNdU33OvSUzPro6AEjkplk1PWwq/+CAPsAN9oAbRP wkeegRzYuOOxJl3OP6u/VJVNd1IJXfdQlAg/oyP01ZPFsb/gkw+0f2p+51yjRFGc5ciK tiD8xyPPyor85Jppvytc1/Dq8331FID2oMP/r++reBSGCyJdIXjUbnhPphZywEGsM12R 65Odep/kHbveItBFH9kT+RGcwTepewplvSaR7PbzZ28eVDCKW93rwFGE08ez1XM7zSGs +X3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=jivGlEn+GA5P/RTObPxVrK3HwT0JxMFF7S9csrWrQvk=; b=gZS0wcsqdxB8fnamXDoVOvuQs2pnvHy+5tmHjRB7GNZddAAtv+PVzOYU6IgJcIWvb9 oum2vqQUK1jWhpo1O2XtYLya354P2L7dzO1xkPtuX622Fcl+p3OtBKgFSqW5GKF5NRe/ wqkcXF5CZrU8UdfQYMet+PDmklZX1cw4GWQUfSR2CldJq1iEh1xBLpC74DKpAZP1D7/Z OHCrDjuOSnH+L8qEOy7M3QxGCF1+RMSpaMIxzy9kWYiKD4Rg0ggiFqNTqGUCJ4FeVgQH hJlDq3kBf6eQAWVOiGrdI7U071XaTobUS/4vBKfWkGJBKWT5xAFPePMK8dkCkK874VxR GGHQ== X-Gm-Message-State: AElRT7HtbH+T3Iojm+oF2oHqgLjhVstL+KrB411EXcR0bEDeQ3+DPdMb VqQ0TxSRC/ET3svw4Z2vPZdoZQ== X-Received: by 10.99.112.20 with SMTP id l20mr4477856pgc.412.1521048644381; Wed, 14 Mar 2018 10:30:44 -0700 (PDT) Received: from localhost ([65.153.83.185]) by smtp.gmail.com with ESMTPSA id l129sm6953012pfl.82.2018.03.14.10.30.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Mar 2018 10:30:43 -0700 (PDT) Date: Wed, 14 Mar 2018 10:30:43 -0700 (PDT) X-Google-Original-Date: Wed, 14 Mar 2018 10:30:00 PDT (-0700) Subject: Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit In-Reply-To: <87d106zine.fsf@xps13.shealevy.com> CC: zong@andestech.com, albert@sifive.com, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, zong@andestech.com, zongbox@gmail.com, greentime@andestech.com From: Palmer Dabbelt To: shea@shealevy.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 14 Mar 2018 10:11:49 PDT (-0700), shea@shealevy.com wrote: > Palmer Dabbelt writes: > >> On Wed, 14 Mar 2018 05:07:09 PDT (-0700), shea@shealevy.com wrote: >>> Palmer Dabbelt writes: >>> >>>> On Tue, 13 Mar 2018 14:30:53 PDT (-0700), shea@shealevy.com wrote: >>>>> Hi Palmer, >>>>> >>>>> Palmer Dabbelt writes: >>>>> >>>>>> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), zong@andestech.com wrote: >>>>>>> These patches resolve the some issues of loadable module. >>>>>>> - symbol out of ranges >>>>>>> - unknown relocation types >>>>>>> >>>>>>> The reference of external variable and function symbols >>>>>>> cannot exceed 32-bit offset ranges in kernel module. >>>>>>> The module only can work on the 32-bit OS or the 64-bit >>>>>>> OS with sv32 virtual addressing. >>>>>>> >>>>>>> These patches will generate the .got, .got.plt and >>>>>>> .plt sections during loading module, let it can refer >>>>>>> to the symbol which locate more than 32-bit offset. >>>>>>> These sections depend on the relocation types: >>>>>>> - R_RISCV_GOT_HI20 >>>>>>> - R_RISCV_CALL_PLT >>>>>>> >>>>>>> These patches also support more relocation types >>>>>>> - R_RISCV_CALL >>>>>>> - R_RISCV_HI20 >>>>>>> - R_RISCV_LO12_I >>>>>>> - R_RISCV_LO12_S >>>>>>> - R_RISCV_RVC_BRANCH >>>>>>> - R_RISCV_RVC_JUMP >>>>>>> - R_RISCV_ALIGN >>>>>>> - R_RISCV_ADD32 >>>>>>> - R_RISCV_SUB32 >>>>>>> >>>>>>> Zong Li (11): >>>>>>> RISC-V: Add sections of PLT and GOT for kernel module >>>>>>> RISC-V: Add section of GOT.PLT for kernel module >>>>>>> RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module >>>>>>> RISC-V: Support CALL relocation type in kernel module >>>>>>> RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module >>>>>>> RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq >>>>>>> RISC-V: Support ALIGN relocation type in kernel module >>>>>>> RISC-V: Support ADD32 relocation type in kernel module >>>>>>> RISC-V: Support SUB32 relocation type in kernel module >>>>>>> RISC-V: Enable module support in defconfig >>>>>>> RISC-V: Add definition of relocation types >>>>>>> >>>>>>> arch/riscv/Kconfig | 5 ++ >>>>>>> arch/riscv/Makefile | 3 + >>>>>>> arch/riscv/configs/defconfig | 2 + >>>>>>> arch/riscv/include/asm/module.h | 112 +++++++++++++++++++++++ >>>>>>> arch/riscv/include/uapi/asm/elf.h | 24 +++++ >>>>>>> arch/riscv/kernel/Makefile | 1 + >>>>>>> arch/riscv/kernel/module-sections.c | 156 ++++++++++++++++++++++++++++++++ >>>>>>> arch/riscv/kernel/module.c | 175 ++++++++++++++++++++++++++++++++++-- >>>>>>> arch/riscv/kernel/module.lds | 8 ++ >>>>>>> 9 files changed, 480 insertions(+), 6 deletions(-) >>>>>>> create mode 100644 arch/riscv/include/asm/module.h >>>>>>> create mode 100644 arch/riscv/kernel/module-sections.c >>>>>>> create mode 100644 arch/riscv/kernel/module.lds >>>>>> >>>>>> This is the second set of patches that turn on modules, and it has the same >>>>>> R_RISCV_ALIGN problem as the other one >>>>>> >>>>>> http://lists.infradead.org/pipermail/linux-riscv/2018-February/000081.html >>>>>> >>>>>> It looks like this one uses shared libraries for modules instead of static >>>>>> objects. I think using shared objects is the right thing to do, as it'll allow >>>>>> us to place modules anywhere in the address space by having multiple GOTs and >>>>>> PLTs. >>>>> >>>>> Can you expand on this? It was my understanding that outside of the >>>>> context of multiple address spaces sharing code the GOT and PLT were >>>>> simply unnecessary overhead, what benefit would they bring here? >>>> >>>> We don't currently have any position-dependent RISC-V code models larger than >>>> "medany", in which all code and data must live within a single 32-bit >>>> addressable range. The PLT and GOT sort of provide an out here, so the code >>>> only needs to get to the table (which can then get anywhere via an indirection >>>> layer). >>>> >>>> This is relevant for Linux modules because it lets us load modules anywhere in >>>> the address space. It's also a bit of a headache, as it either requires a >>>> GOT+PLT per module (which is big) or merging tables (which is hard). >>> >>> I see, thanks! We only get this benefit if we actually do the relevanat >>> indirection in the table, right? And if we merge tables we still have to >>> have all modules within 32 bits of the common table? Is this how some >>> future "medlarge" code model will work, or is it more of a convenient >>> way to reuse existing techniques until other code models are worked out? >> >> The idea is that you'd merge the tables only when it's possible to do that >> correctly, which is the tricky part. >> >> It'd be called "largeany", the "med" part is what limits the code model to 32 >> bit offsets. We might just call it "large", as the "any" is kind of redundant. > > Ah, right, that makes more sense :D. So would "mcmodel=large" also use > PLTs/GOTs for long jumps? We'd probably still restrict the size of single object files to 32-bit offsets, but jumps outside of an object file would use an offset table. Of course, none of this is set in stone yet because we haven't fully figured out how to make this all work.