discuss-gnustep
[Top][All Lists]
Advanced

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

Re: universal binaries


From: Frederico Muñoz
Subject: Re: universal binaries
Date: Sun, 16 Sep 2007 15:35:15 +0100

Hello,


On 9/16/07, Graham J Lee <leeg@thaesofereode.info> wrote:
> On 16 Sep 2007, at 03:35, Frederico Muñoz wrote:

(...)
> > "(...)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 ;-)
>

True.

> > 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).

Yes, the format seems to assume a direct link between CPU architecture
and underlying OS. I *think* that the NeXTStep fat binaries used the
same analogy, with Solaris linked to Sparc and HP-UX to PA-RISC.

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

Yes, with multiple OS's possible for any given architecture the CPU
approach is simplistic. One possible way would be to use the CPU
subtype flag to indicate a CPU+OS pair (I'm not even considering
different libc). This could work, although it would be a kludge.
Another would be to use just one such flag to indicate a GNUstep
binary, which in turn would have a more rich format which could
contain multiple binaries. Possible, but perhaps not elegant. In the
end I'm not sure that MAB's are worth the trouble given all this if
one takes out the "coolness " factor (i.e. the exact some app running
on OSX and GNUstep), which is perhaps somethings that appeals on a
more emotional level than purely practical.

Cheers,

Frederico Muñoz




reply via email to

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