Received: by 10.213.65.68 with SMTP id h4csp738688imn; Tue, 13 Mar 2018 20:52:44 -0700 (PDT) X-Google-Smtp-Source: AG47ELtO4V5ogChokYD5IdAx2UOBNUYu1u39ahdRI4+Ss4onBSyrC1QS29ot8GrKwpATkj5Qr349 X-Received: by 10.98.76.26 with SMTP id z26mr2887695pfa.220.1520999564517; Tue, 13 Mar 2018 20:52:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520999564; cv=none; d=google.com; s=arc-20160816; b=qJat1mgh4t7LkXHZrjOom4XMm6MJuE1SXt7hQ70WMTIKJS+iMxH0RldRJLRB2vMweH kCs1d5ki/QO0r9a7TYdZ0CJUnHX5RrWk+odE4LxN3HacGyenPLeqEDqux4H0CjIwQpc+ aeCpiSgKURbsZHkRCFJZ9xeaoRuw6aiTLzxUfM8JolCrfN0c15UTFET11GA1r7W6HF9p xFyvKpUGYywj4SlgTZaCyZlags3iJuyKjQGv/PyE3ZAaOJu4fKkNYPlaNIxa/NoW3vHZ JM06oZYMsNv/ZxuwVS9rI53fi+qdU2zDGLTH2vzmVtyF05VFqVHxSj2Asq9K9ddDQ66I ZGcg== 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=e20nVdbQCP2BygMxCkGxYHgwuGc/Q7cliDf9mkba4uE=; b=b+adc00Ym4TbZXo5cifdM3FTQ41Fjh0ncAcghnbrTa0CU8Nsm7jmxJvi88JsybI/8T rM8GZcNt4jbNqUEDMs6VGJXeVYJHidb090CqyK1p7BuHxkhP2Osv1RP4DbVd9Drrp02a SpHHIBcxQtj5OeN3E7IGh5evmfuXT4l5dXQ+JJUiM9wbuX4WbyBLHd/bB9IggXEY4Tf9 OQVqeRX/t0tP2WB/duJJkvt2+LZXs6r0KXIfUInr2WJtH4YdYDQ19ccqUXbAxVXlX0Zg WqUvd7c50nqcfs7s4zdz9FBsByh5cARIpRqc4Dgt/FlD+b5nUilaDcHl/NuPamhgfjXB Qu8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=jGOzUCE/; 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 s10si1367219pfi.143.2018.03.13.20.52.30; Tue, 13 Mar 2018 20:52:44 -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=jGOzUCE/; 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 S933286AbeCNDvd (ORCPT + 99 others); Tue, 13 Mar 2018 23:51:33 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:46775 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932842AbeCNDvc (ORCPT ); Tue, 13 Mar 2018 23:51:32 -0400 Received: by mail-pf0-f195.google.com with SMTP id z10so856660pfh.13 for ; Tue, 13 Mar 2018 20:51:31 -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=e20nVdbQCP2BygMxCkGxYHgwuGc/Q7cliDf9mkba4uE=; b=jGOzUCE/x7AC294dqASMIQLsNOOodtsTUi1BbWNT9BwcO3I3UJaeVOJtH8sUsC8WCd Bh7juVODomQpxboOdYTbPWIXrZOe6kGUTn3CtJFOAZ20ZylGVsmJFVkIi54xbQ0KzP/m xwy2hyC1hlKS82RTBcoxf1mA34sxpZguAAnPnIQdI/gFMmGrjenP8+De5PXxFluS4hgo VZU+qssTFsN+hG/8VJkFmmfWJ9GFlnFoZkWbfEl9cxyQNjcJVYj7dGGnbnafqfGqkUt3 XgE0z6uBAjSh/Sxs82Qif7HnjkerFwd8/V6HnMIuXiSUbqUHakpaf6+Ks64PlODRhnI0 AJVw== 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=e20nVdbQCP2BygMxCkGxYHgwuGc/Q7cliDf9mkba4uE=; b=QpKQ6SHcVu7gc9NHn+QHjJA+g9HHNlCqjzsDNgAxClRWwuRUHNKJyeKy8R65zuAqn5 zI8dSjz3E3IyZQL2tqe21flVMvPI02pf5VR6fZZkXWv0VRsDrggoliF41j8wdm/CKdZQ du8Mtac0RNynuHR6QvIXoVYvlKvywZA4Hyr/jxeAEOmud0fhqP6ky0cGq+HO8dMuaTAe PXwucKgyRo55oZAsciA90MYvJFDWx9aYPBkpYn18ksyjyPxGnEFGZ7ErbIphfP05MCpz ip4O6wBdcY1lpe1b4qVkSFp0rbelh2u1QmQucK0MP2KXlUq/JWPN3PsS7v/ptQFx+qz2 ay8w== X-Gm-Message-State: AElRT7HVgfBV/Xf8iymYt4c/4xy+UFSUss9wz6Tv00HA2T3uklNEr5ti s37JohapT5DlnibmVaVFY6So4Q== X-Received: by 10.99.110.131 with SMTP id j125mr2440801pgc.382.1520999491260; Tue, 13 Mar 2018 20:51:31 -0700 (PDT) Received: from localhost ([65.153.83.185]) by smtp.gmail.com with ESMTPSA id y186sm2351769pfb.92.2018.03.13.20.51.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 20:51:30 -0700 (PDT) Date: Tue, 13 Mar 2018 20:51:30 -0700 (PDT) X-Google-Original-Date: Tue, 13 Mar 2018 20:46:00 PDT (-0700) Subject: Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit In-Reply-To: <87sh93zmr6.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 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).