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

[J. Mayer]

On Sun, 2007-10-07 at 17:38 +0300, Blue Swirl wrote:
> On 10/7/07, J. Mayer <address@hidden> 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 ?

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

-- 
J. Mayer <address@hidden>
Never organized