From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1ClwK1-0007uN-Ih for qemu-devel@nongnu.org; Tue, 04 Jan 2005 16:34:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1ClwJz-0007tC-A8 for qemu-devel@nongnu.org; Tue, 04 Jan 2005 16:34:31 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClwJz-0007sw-5R for qemu-devel@nongnu.org; Tue, 04 Jan 2005 16:34:31 -0500 Received: from [65.74.133.9] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Clw8h-0001YG-Ju for qemu-devel@nongnu.org; Tue, 04 Jan 2005 16:22:51 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Endian and userspace issues Date: Tue, 4 Jan 2005 21:22:48 +0000 References: <200501042016.03910.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501042122.49111.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: anarkhos@vfemail.net Cc: qemu-devel@nongnu.org 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