Message-ID: <b3ec8b21-8776-98e1-b7e2-f82bdee40602@kernel.org>
Date:   Wed, 1 Mar 2023 10:24:05 +1000
From:   Greg Ungerer <gerg@...nel.org>
To:     Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Niklas Cassel <Niklas.Cassel@....com>
Cc:     linux-riscv@...ts.infradead.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] riscv: support ELF format binaries in nommu mode

Hi Damien,

On 1/3/23 08:49, Damien Le Moal wrote:
> On 3/1/23 06:52, Palmer Dabbelt wrote:
>> On Tue, 28 Feb 2023 05:51:24 PST (-0800), gerg@...nel.org wrote:
>>> The following changes add the ability to run ELF format binaries when
>>> running RISC-V in nommu mode. That support is actually part of the
>>> ELF-FDPIC loader, so these changes are all about making that work on
>>> RISC-V.
>>>
>>> The first issue to deal with is making the ELF-FDPIC loader capable of
>>> handling 64-bit ELF files. As coded right now it only supports 32-bit
>>> ELF files.
>>>
>>> Secondly some changes are required to enable and compile the ELF-FDPIC
>>> loader on RISC-V and to pass the ELF-FDPIC mapping addresses through to
>>> user space when execing the new program.
>>>
>>> These changes have not been used to run actual ELF-FDPIC binaries.
>>> It is used to load and run normal ELF - compiled -pie format. Though the
>>> underlying changes are expected to work with full ELF-FDPIC binaries if
>>> or when that is supported on RISC-V in gcc.
>>>
>>> To avoid needing changes to the C-library (tested with uClibc-ng
>>> currently) there is a simple runtime dynamic loader (interpreter)
>>> available to do the final relocations, https://github.com/gregungerer/uldso.
>>> The nice thing about doing it this way is that the same program
>>> binary can also be loaded with the usual ELF loader in MMU linux.
>>>
>>> The motivation here is to provide an easy to use alternative to the
>>> flat format binaries normally used for RISC-V nommu based systems.
>>>
>>> Signed-off-by: Greg Ungerer <gerg@...nel.org>
>>> ---
>>>
>>>   arch/riscv/include/asm/elf.h         |   11 +++++++++-
>>>   arch/riscv/include/asm/mmu.h         |    4 +++
>>>   arch/riscv/include/uapi/asm/ptrace.h |    5 ++++
>>>   fs/Kconfig.binfmt                    |    2 -
>>>   fs/binfmt_elf_fdpic.c                |   38 +++++++++++++++++------------------
>>>   include/linux/elf-fdpic.h            |   14 +++++++++++-
>>>   include/uapi/linux/elf-fdpic.h       |   15 +++++++++++++
>>>   7 files changed, 67 insertions(+), 22 deletions(-)
>>
>> Adding Damien, as IIRC he's had some hacked up userspace bits for the
>> K210.  I'm yet to get anything running, but it'd be great if we get this
>> to a point where I can actually boot test this on QEMU (I'm just doing
>> builds now).
> 
> +Niklas
> 
> Niklas, didn't you add a nommu qemu build for buildroot ? Can't find the config
> though...
> 
>>
>> Given that it's the second week of the merge window and this is a bunch
>> of new uABI it seems best to hold off until the next cycle.  I poked
>> around and don't see anything wrong, but I'll try and take a more
>> detailed look after the merge window.
> 
> Does any riscv compiler support nommu fdpic now ? When doing the work on the
> k210, there was no support at all, hence the statically linked user binaries
> used (no shared text for libraries).

I was wondering if anyone was working on it. Couldn't find anything.

The way I use this support doesn't improve the statically linked situation.
The -pie ELF files are still statically linked. But it does avoid the
use of flat format binaries. That makes the toolchain generation a little
simpler.

Regards
Greg

Powered by blists - more mailing lists