Re: [Qemu-devel] Endian and userspace issues

[Paul Brook <paul@codesourcery.com>]

On Tuesday 04 January 2005 20:37, anarkhos@vfemail.net wrote:
> >However shared libraries tend to have much less cleanly defined
> > interfaces. They tend do share data structures, and be much more closely
> > linked. This makes adding the translation layer between the two much more
> > difficult, if not impossible. It generally requires designing the
> > interface with this in mind from the start, and in general can't be
> > retrofitted to existing libraries. Shared libraries (aka dlls) share an
> > address space with the main application, so tend to be very hard to
> > disentangle from each other.
> >
> >Paul
>
> I can see your point in that if a non-native app passed an address to a
> space of little endian memory to a native DLL which required big-endian
> memory...but my suggestion was that everything would be native-endian after
> one initial translation.

This only works in trivial cases. For instance anything involving 64-bit 
arithmetic on a 32-bit machine will load a 64-bit value with two separate 
32-bit loads. After your translation these will be the wrong way round.

> PS: WINE can insert thunk layers between the app and DLLs or between the
> DLLs. It currently does this for debugging purposes (printing arguments and
> return values), but could it not convert these values before passing them
> on?

But WINE knows the details of the libraries it is thunking, and can only do it 
for specific dlls, right?

Translating function arguments requires source level knowledge if the library 
(how many and what type of arguments to expect). If you only have simple 
arguments/return values this is ok, when pointers and structures are involved 
it becomes much more complicated because you need to know the purpose of each 
field.

This is reasonably straightforward if implemented at the source level (either 
library or applicaton is annotated properly and compiled specifically for 
this). For a specific special case interface (eg. mozilla plugins), it should 
be possible with a bit of work (depends on the interface). AFAICS it is not 
possible to implement a general code that will work with arbitrary 
libraries/libraries.

Paul