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