[PATCH v5 02/13] x86/um: nommu: elf loader for fdpic
Hajime Tazaki
thehajime at gmail.com
Thu Dec 12 23:19:46 PST 2024
Hello Eric,
thanks for the feedback.
On Thu, 12 Dec 2024 23:22:47 +0900,
Eric W. Biederman wrote:
>
> Hajime Tazaki <thehajime at gmail.com> 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
More information about the linux-um
mailing list