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;
From:   Shea Levy <shea@shealevy.com>
To:     Palmer Dabbelt <palmer@sifive.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
Subject: Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit
In-Reply-To: <mhng-fd5e759c-7716-41b2-9fa3-439d6b4b498f@palmer-si-x1c4>
References: <mhng-fd5e759c-7716-41b2-9fa3-439d6b4b498f@palmer-si-x1c4>
Date:   Wed, 14 Mar 2018 13:11:49 -0400
Message-ID: <87d106zine.fsf@xps13.shealevy.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha256; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--=-=-=
Content-Type: text/plain

Palmer Dabbelt <palmer@sifive.com> writes:

> On Wed, 14 Mar 2018 05:07:09 PDT (-0700), shea@shealevy.com wrote:
>> Palmer Dabbelt <palmer@sifive.com> writes:
>>
>>> On Tue, 13 Mar 2018 14:30:53 PDT (-0700), shea@shealevy.com wrote:
>>>> Hi Palmer,
>>>>
>>>> Palmer Dabbelt <palmer@sifive.com> 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?

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE6ESKvwKkwnxgMLnaXAvWlX2G/icFAlqpV9UACgkQXAvWlX2G
/ieR9hAAmSPEP427jCH06I7r5D/ghxyNwBD3rFpDF4np7YttTBre4LwF5FZzuwgj
e6qP09XTjDBGkB/5P+R7MmmuzFoV/lwmKHIV+oUmDkztTyU1BJO/qHsJ+P+G36hr
HwxzcY5ZU7uRjBqp0Fqmt808qJEIaYo4wT/pojw03iMeicSY0PQdJv0fMGoZgSZ5
rOQf6UoGdcd/TKM5+BPSIaXBIg/LYwYwEeirgD9DyUxJGY2LUKcal38XPh9x25V2
sEAfTB6w7kw/RMM7jBXeX+11nNGOffX1KM1swryui1gqc9uzBKrbNgtZwIoZ9O3/
wkSewFeuqnpQF6BpS0fk9cV7yz9b29x2+k8WJ/Xvntm8OSnAX3U3cY5rFQECk5tM
b440pcRCqnYACXHLqciC7tE6gQ0LF4VxE9EB+UNoQWWcoVvrh36CPGrIux6iechU
eGR0Hle8BRgDPSmAEJRZ9GTID+GAh7tP0Sr3/xpHsQyGHVSiQj2jnfZEAIT4zD7j
R85tR4497HiUfasdpF7QdcWqaaRuPVQoijJsI2N+aGPo/m1R0reqfgbO461qQGif
1A511wTt4s3O90ARo8d0fhoYd8YR+oGZP1Zs3lRGHktjXrRM8KIlZJAPYZxLWoBp
AS16IHKWvZtPs8gqJbgagyhpGUU5tw6xmwFW2dHPXeR3JuOw98Q=
=8lMD
-----END PGP SIGNATURE-----
--=-=-=--