Hajime Tazaki <thehajime@xxxxxxxxx> writes: > Hello Eric, > > thanks for the feedback. > > On Thu, 12 Dec 2024 23:22:47 +0900, > Eric W. Biederman wrote: >> >> Hajime Tazaki <thehajime@xxxxxxxxx> writes: >> >> > As UML supports CONFIG_MMU=n case, it has to use an alternate ELF >> > loader, FDPIC ELF loader. In this commit, we added necessary >> > definitions in the arch, as UML has not been used so far. It also >> > updates Kconfig file to use BINFMT_ELF_FDPIC under !MMU environment. >> >> Why does the no mmu case need an alternative elf loader? > > I was simply following the way how other nommu architectures (riscv, > etc) did. > >> Last time I looked the regular binfmt_elf works just fine >> without an mmu. I looked again and at a quick skim the >> regular elf loader still looks like it will work without >> an MMU. > > I'm wondering how you looked at it and how you see that it works > without MMU. I got as far as seeing that vm_mmap should work. As all of the bits for mmap to work, are present in both mmu and nommu. >> You would need ET_DYN binaries just so they will load and run >> in a position independent way. But even that seems a common >> configuration even with a MMU these days. > > Yes, our perquisite for this nommu port is to use PIE binaries so, > ET_DYN assumption works fine for the moment. > >> There are some funny things in elf_fdpic where it departs >> from the ELF standard and is no fun to support unless it >> is necessary. So I am not excited to see more architectures >> supporting ELF_FDPIC. > > I understand. > > I also wish to use the regular binfmt_elf, but it doesn't allow me to > compile with !CONFIG_MMU right now. Then I may simply be confused. Where does the compile fail? Is it somewhere in Kconfig? I could be completely confused. It has happened before. I just react a little strongly to the assertion that elf_fdpic is the only path when I don't see why that should be. Especially for an architecture like user-mode-linux where I would expect it to run the existing binaries for a port. > I've played a little bit with touching binfmt_elf.c, but not finished > yet with a trivial attempt. > > sorry, i'm not familiar with this part but wish to fix it for > nommu+ET_EYN if possible with a right background information. Eric
