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(-)
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@kernel.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(-)
On Tue, 28 Feb 2023 05:51:24 PST (-0800), gerg@kernel.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@kernel.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). 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. Thanks!
Hi Palmer, On 1/3/23 07:52, Palmer Dabbelt wrote: > On Tue, 28 Feb 2023 05:51:24 PST (-0800), gerg@kernel.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@kernel.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). This is a simple script I user to generate a working QEMU example: https://raw.githubusercontent.com/gregungerer/simple-linux/master/build-riscvnommu-linux-uclibc-elf.sh It does reference some configs here https://github.com/gregungerer/simple-linux/tree/master/configs and this posted patchset as https://github.com/gregungerer/simple-linux/tree/master/patches (this is just these 2 patches combined as a single patch). > 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. Oh, yeah, no hurry. Regards Greg
On Tue, 28 Feb 2023 16:20:35 PST (-0800), gerg@kernel.org wrote: > Hi Palmer, > > On 1/3/23 07:52, Palmer Dabbelt wrote: >> On Tue, 28 Feb 2023 05:51:24 PST (-0800), gerg@kernel.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@kernel.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). > > This is a simple script I user to generate a working QEMU example: > > https://raw.githubusercontent.com/gregungerer/simple-linux/master/build-riscvnommu-linux-uclibc-elf.sh > > It does reference some configs here https://github.com/gregungerer/simple-linux/tree/master/configs > and this posted patchset as https://github.com/gregungerer/simple-linux/tree/master/patches (this is > just these 2 patches combined as a single patch). > > >> 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. > > Oh, yeah, no hurry. Maciej and Damien: I'm fine taking this, but not in any rush. I'd rather get the uABI right if things are still in flight, but if we're all just waiting for something to get merged first then I'm fine with that being Linux. > > Regards > Greg
On 3/15/23 12:58, Palmer Dabbelt wrote: > On Tue, 28 Feb 2023 16:20:35 PST (-0800), gerg@kernel.org wrote: >> Hi Palmer, >> >> On 1/3/23 07:52, Palmer Dabbelt wrote: >>> On Tue, 28 Feb 2023 05:51:24 PST (-0800), gerg@kernel.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@kernel.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). >> >> This is a simple script I user to generate a working QEMU example: >> >> https://raw.githubusercontent.com/gregungerer/simple-linux/master/build-riscvnommu-linux-uclibc-elf.sh >> >> It does reference some configs here https://github.com/gregungerer/simple-linux/tree/master/configs >> and this posted patchset as https://github.com/gregungerer/simple-linux/tree/master/patches (this is >> just these 2 patches combined as a single patch). >> >> >>> 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. >> >> Oh, yeah, no hurry. > > Maciej and Damien: I'm fine taking this, but not in any rush. I'd > rather get the uABI right if things are still in flight, but if we're > all just waiting for something to get merged first then I'm fine with > that being Linux. I did not try Gerg script with the k210. No time right now. But if it works with QEMU, should be fine. > >> >> Regards >> Greg -- Damien Le Moal Western Digital Research
On 3/1/23 06:52, Palmer Dabbelt wrote: > On Tue, 28 Feb 2023 05:51:24 PST (-0800), gerg@kernel.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@kernel.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). -- Damien Le Moal Western Digital Research
On Wed, Mar 01, 2023 at 07:49:05AM +0900, Damien Le Moal wrote: (snip) > > 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... Yes, I did. In buildroot: $ make qemu_riscv64_nommu_virt_defconfig The QEMU command line generated by buildroot: qemu-system-riscv64 -M virt -bios none -kernel output/images/Image -append "rootwait root=/dev/vda ro" -drive file=output/images/rootfs.ext2,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -nographic -cpu rv64,mmu=off # qemu_riscv64_nommu_virt_defconfig Compared to a regular riscv64 QEMU command line, the relevant parameter is: -cpu rv64,mmu=off Kind regards, Niklas
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@kernel.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@kernel.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
On 3/1/23 09:24, Greg Ungerer wrote: > 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@kernel.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@kernel.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. Maciej (added to this thread) has done some work on gcc, but nothing that is upstream yet. > 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. Right. I was still thinking in terms of flat bin. The keyword here is "elf"... Need more coffe :) We could try this using either qemu or the k210 with buildroot, with the addition of your uldso loader. Will try to put that in the pipeline (pretty full as usual, so may take a while). > > Regards > Greg > -- Damien Le Moal Western Digital Research
On Tue, 28 Feb 2023, Palmer Dabbelt wrote: > 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). And I'm still around should someone want to proceed with FDPIC support in the toolchain. Maciej
© 2016 - 2025 Red Hat, Inc.