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. > 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. 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. -- Hajime
