discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: universal binaries


From: Graham J Lee
Subject: Re: universal binaries
Date: Sun, 16 Sep 2007 14:39:43 +0100

On 16 Sep 2007, at 03:35, Frederico Muñoz wrote:


Indeed. The most simple and complete explanation I've found is at
http://hohle.net/scrap_post.php?post=197. Basically it doesn't seem
tied to Mach-O in the sense that the binary format doesn't seem to
offer any special support for it. In the end it seems as a "simple"
archive format that works by having a cooperating exec:

"(...)The first block contains the "Magic Number". This is how OS X
knows what kind of binary its going to try to run. CAFEBABE, is the
magic number used for fat binaries. The second number is for the
number of archives in the binary.(...)Next come the headers for each
of the binaries. The first block indicates the CPU Type, and the CPU
Subtype. From this example, it would seem that 0x12 is PowerPC, and
0x7 is x86. The next block is the CPU Subtype. Again, for this
example, the subtype for PowerPC is empty (0x0), and the Intel SubType
is 0x3.

which is actually i386+ even though the compiler produces objects which would never work on the i386 ;-)

Next comes different information about the addressing of the archive.
We see the offset, which tells us where the program starts in this
file, and how large that block is(...)"


With Mach-o?

I don't think this is limited to some sort of ABI other than by
patent issues. In principle, you should even be able to stitch
together mach-o and ELF binaries. You'd have to modify the current
Mac OS X kernel to get this working.

Indeed, I see no reason for not being possible to have ELF and Mach-O
mixed in the same MAB (which is not saying much since I know very
little on how these things are processed at this level).

The main problem with Mach-O style fat files is that they aren't expressive enough. For instance, it's reasonable to assume that if you've got a PPC Mach-O segment, it's designed for Darwin (it might instead be a Rhapsody binary which Darwin can't load, but the chances are small; similarly few OPENSTEP users are going to try deploying OS4.x binaries to Mac OS X for Intel). But that's not good enough for GNUstep; is an 'i386/I386_SUBTYPE_ANY' ELF binary destined for Linux, HURD, Solaris, FreeBSD...? While it's true that a good ELF loader would nicely fail if presented with a wrong object, it'd be better to have a wrapper format specifying the OS in some way to provide a truly cross-target fat file format.

Cheers,
Graham.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]