On 4/25/10, Richard Henderson <r...@twiddle.net> wrote: > On 04/23/2010 11:36 AM, Blue Swirl wrote: > > On 4/23/10, Richard Henderson <r...@twiddle.net> wrote: > >> The ABI-specific types used by linux_binprm and image_info > >> are different after forcing TARGET_ABI32 on. Which means > >> that the parameters that load_elf_binary_multi sees are not > >> those that loader_exec passed. This is inherently broken > >> and is more trouble than it's worth fixing. > > > > Nack. How is this inherently broken? > > > sizeof(abi_ulong) is different in elfload32.c and linuxload.c, > which means the two files cannot communicate with any type > affected by this change. Which is both linux_binprm and image_info. > > > > The problem that elfload32 solves is that the CPU is 64 bit, but the > > ABI and the binaries loaded are still 32 bits. It works nicely for > > sparc32plus binaries (ELFCLASS32, but only for V9 CPUs). > > > And yet we have a separate sparc32plus-linux-user/qemu-sparc32plus > binary that does that job. > > Do we really need qemu-sparc64 to do both jobs? Because it doesn't. > The only thing that happens is that qemu crashes immediately because > it sees linux_binprm.e_gid at the offset it expects to see > linux_binprm.argc, and fails to copy gid=rth(5000) entries from the > argv array.
I see. Thanks, applied.
