[Qemu-devel] User mode issue for loading 32-bit ELF on 64-bit guest processor

[Qemu-devel] User mode issue for loading 32-bit ELF on 64-bit guest processor

[Laurent Desnogues]

Hello,

while playing with sparc64 Linux user mode emulation, I tried
to run a 32-bit v8plus executable;  this may not work according
to Blue Swirl, but that's not the issue I had.

Currently elfload32.c forces the definition of TARGET_ABI32
before including elfload.c.  This notably results in abi_ulong
being forced as a 32-bit integer.  In turn this will change some
structure layouts such as linux_binprm and image_info which
are parameters of load_elf_binary/load_elf_binary32.  But
linuxload.c/loader_exec uses the standard 64-bit integer for
defining abi_ulong.  In the end this segfaults when accessing
fields of linux_binprm when trying to load a 32-bit ELF.

I am not sure what is the cleanest way to fix that problem.  As
a quick hack I just inserted uint32_t fields after each abi_ulong
field in linux_binprm and image_info structures when
TARGET_ABI32 is defined (I know this is not generally correct,
it was just a way to check my understanding was right).

Blue Swirl proposed to use accessors for these structures
while I proposed to use a new abi_ulong-like type that would
be the same no matter whether TARGET_ABI32 is defined or
not.  As I am not sure there aren't some other structures that
would need such a type, I think my proposal is less intrusive.
The drawback is that it would introduce a new type and we
already have many such *_ulong types :-)

What do people think?


Laurent

Re: [Qemu-devel] User mode issue for loading 32-bit ELF on 64-bit guest processor

[Paul Brook]

> Blue Swirl proposed to use accessors for these structures
> while I proposed to use a new abi_ulong-like type that would
> be the same no matter whether TARGET_ABI32 is defined or
> not.  As I am not sure there aren't some other structures that
> would need such a type, I think my proposal is less intrusive.
> The drawback is that it would introduce a new type and we
> already have many such *_ulong types :-)

I'm confused. Isn't this either target_ulong or abi_ulong?
I don't see what other possibilities there are.

Paul

Re: [Qemu-devel] User mode issue for loading 32-bit ELF on 64-bit guest processor

[Laurent Desnogues]

On Wed, Jan 21, 2009 at 6:40 AM, Paul Brook <paul@codesourcery.com> wrote:
>> Blue Swirl proposed to use accessors for these structures
>> while I proposed to use a new abi_ulong-like type that would
>> be the same no matter whether TARGET_ABI32 is defined or
>> not.  As I am not sure there aren't some other structures that
>> would need such a type, I think my proposal is less intrusive.
>> The drawback is that it would introduce a new type and we
>> already have many such *_ulong types :-)
>
> I'm confused. Isn't this either target_ulong or abi_ulong?
> I don't see what other possibilities there are.

Indeed these *_ulong types can be confusing especially in
that case where elfload32.c sets TARGET_ABI32 before
including elfload.c which includes qemu.h and then
qemu-types.h which looks like this:

#ifdef TARGET_ABI32
typedef uint32_t abi_ulong;
#else
typedef target_ulong abi_ulong;
#endif

and then qemu.h defines the structures that cause trouble.


Laurent