Re: [Qemu-devel] [RFC, PATCH] Support for loading 32 bit ELF files for 64 bit linux-user

["Blue Swirl" <blauwirbel@gmail.com>]

On 10/7/07, J. Mayer <l_indien@magic.fr> wrote:
> On Sun, 2007-10-07 at 17:38 +0300, Blue Swirl wrote:
> > On 10/7/07, J. Mayer <l_indien@magic.fr> wrote:
> > > On Sun, 2007-10-07 at 15:45 +0300, Blue Swirl wrote:
> > > > Hi,
> > >
> > > Hi,
> > >
> > > > This patch adds support for loading a 32 bit ELF file in the 64 bit
> > > > user mode emulator. This means that qemu-sparc64 can be used to
> > > > execute 32 bit ELF files containing V9 instructions (SPARC32PLUS).
> > > > This format is used by Solaris/Sparc and maybe by Debian in the
> > > > future.
> > > >
> > > > Other targets shouldn't be affected, but I have done only compile
> > > > testing. Any comments?
> > >
> > > The idea of loading 32 bits executables on 64 bits target seems great.
> > > Then, I got two remarks about this patch:
> > > - it seems that it does not take care about my patch. As I was to commit
> > > it today, I wonder if I still should do it. But then, your patch lacks
> > > some bugifxes (start_data not properly computed and TARGET_LONG_BITS !=
> > > HOST_LONG_BITS problems).
> >
> > Well, I thought that you had already applied the patch.
>
> OK, do you agree that I apply it and you take the changes in yours ?

Yes, the patch looks OK (haven't tested it) and if something still
breaks, we can fix it.

> >
> > > - it seems that quite all the ELF loader code is affected by your patch.
> > > I think (maybe too naively) that adding functions to read the ELF infos
> > > should be sufficient, ie add a read_elf_ehdr, ..., functions and a few
> > > patches in the create_elf_table function. Then, all informations nedded
> > > to load a 32 bits executable can be kept into the 64 bits structures. As
> > > the kernel does not duplicate the code to handle this case, I think Qemu
> > > loader should be kept as simple as the kernel one, and the elfload_ops.h
> > > seems to me to be useless. In fact, Qemu loader could (should ?) even be
> > > the same code than the kernel one with just a few helpers for endianness
> > > swaps and the needed fixes to avoid confusions between host_long and
> > > target_long...
> >
> > Sparc64 Linux handles 32 bit ELF binaries (both V8 = 32 bit insn and
> > V9 = 64 bit insn) in arch/sparc64/kernel/binfmt_elf32.c, which
> > #includes fs/binfmt_elf.c.
> > 64 bit V9 binaries are handled by fs/binfmt_elf.c.
> >
> > In Qemu we can't do it like this, because V9 instruction emulator must
> > be used to handle also the 32 bit ELF. The same effect could be
> > achieved in Qemu for example by adding new file elfload_32.c, which
> > would include elfload.c after defining the ELF classes etc. This would
> > need some rearranging in elfload.c so that the ELF parameters can be
> > overridden. I'm not sure this would be much cleaner than my version
> > using glue().
>
> OK, then if the kernel duplicates the compiled code, it means that this
> way of doing might be the proper one. Couldn't you do something closest
> to what the kernel do, ie moving the per target definitions located at
> the top of elfload.c somewhere else and add a elfload_32.c file that
> would include elfload.c redefining all needed variable types, ... ? This
> just to keep the code as close as possible to the kernel one, even if it
> functionnaly changes nothing...

I'll try if that works. It could be a better approach after all.