On 6/25/19 8:31 AM, Palmer Dabbelt wrote: > On Mon, 24 Jun 2019 06:08:50 PDT (-0700), vladimir.murzin@xxxxxxx wrote: >> On 6/24/19 12:54 PM, Christoph Hellwig wrote: >>> On Mon, Jun 24, 2019 at 12:47:07PM +0100, Vladimir Murzin wrote: >>>> Since you are using binfmt_flat which is kind of 32-bit only I was expecting to see >>>> CONFIG_COMPAT (or something similar to that, like ILP32) enabled, yet I could not >>>> find it. >>> >>> There is no such thing in RISC-V. I don't know of any 64-bit RISC-V >>> cpu that can actually run 32-bit RISC-V code, although in theory that >>> is possible. There also is nothing like the x86 x32 or mips n32 mode >>> available either for now. >>> >>> But it turns out that with a few fixes to binfmt_flat it can run 64-bit >>> binaries just fine. I sent that series out a while ago, and IIRC you >>> actually commented on it. >>> >> >> True, yet my observation was that elf2flt utility assumes that address >> space cannot exceed 32-bit (for header and absolute relocations). So, >> from my limited point of view straightforward way to guarantee that would >> be to build incoming elf in 32-bit mode (it is why I mentioned COMPAT/ILP32). >> >> Also one of your patches expressed somewhat related idea >> >> "binfmt_flat isn't the right binary format for huge executables to >> start with" >> >> Since you said there is no support for compat/ilp32, probably I'm missing some >> toolchain magic? >> >> Cheers >> Vladimir > To: Christoph Hellwig <hch@xxxxxx> > CC: vladimir.murzin@xxxxxxx > CC: Christoph Hellwig <hch@xxxxxx> > CC: Paul Walmsley <paul.walmsley@xxxxxxxxxx> > CC: Damien Le Moal <Damien.LeMoal@xxxxxxx> > CC: linux-riscv@xxxxxxxxxxxxxxxxxxx > CC: linux-mm@xxxxxxxxx > CC: linux-kernel@xxxxxxxxxxxxxxx > Subject: Re: RISC-V nommu support v2 > In-Reply-To: <20190624131633.GB10746@xxxxxx> > > On Mon, 24 Jun 2019 06:16:33 PDT (-0700), Christoph Hellwig wrote: >> On Mon, Jun 24, 2019 at 02:08:50PM +0100, Vladimir Murzin wrote: >>> True, yet my observation was that elf2flt utility assumes that address >>> space cannot exceed 32-bit (for header and absolute relocations). So, >>> from my limited point of view straightforward way to guarantee that would >>> be to build incoming elf in 32-bit mode (it is why I mentioned COMPAT/ILP32). >>> >>> Also one of your patches expressed somewhat related idea >>> >>> "binfmt_flat isn't the right binary format for huge executables to >>> start with" >>> >>> Since you said there is no support for compat/ilp32, probably I'm missing some >>> toolchain magic? >> >> There is no magic except for the tiny elf2flt patch, which for >> now is just in the buildroot repo pointed to in the cover letter >> (and which I plan to upstream once the kernel support has landed >> in Linus' tree). We only support 32-bit code and data address spaces, >> but we otherwise use the normal RISC-V ABI, that is 64-bit longs and >> pointers. > > The medlow code model on RISC-V essentially enforces this -- technically it > enforces a 32-bit region centered around address 0, but it's not that hard to > stay away from negative addresses. That said, as long as elf2flt gives you an > error it should be fine because all medlow is going to do is give you a > different looking error message. > Thanks for explanation! Vladimir
