lkml.org 
[lkml]   [1997]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: FAT binaries and Linux
Date
Richard Henderson wrote:
> Hah. Sharing data is _very_ hard.

No, it's very easy if you don't try to be clever, see below ;-)

> You'd have to modify the compiler to get it to output things that
> you can expect to be able to share in separate sections (easy).
> This is basicly limited to strings,

Not even that ! People may encode things like magic numbers in strings,
which are then copied to and used as integer types. This is of course
ugly, but you can't be sure it's not done somewhere ...

What I'm actually most concerned about are programs that "learn" what
the architecture is like before compilation, e.g. Perl determines the
byte order in Configure. There's no automatic way of getting FAT
binaries for such programs right or even only to reliably refuse
their creation.

> unless you want to muck with
> partially shared sections (sparc shares with ppc, but i386 and
> alpha don't share with anyone due to endian and word size).

Don't forget alignment, architecture-specific system headers like
sys/types.h (__u32, etc.), architecture-specific numbering schemes
(errno.h and such), etc. You can get it right, though: once you've
created all the data areas, you can simply bit-compare them to see
if there happen to be identical ones, then merge. Of course, given
the constraints, merging doesn't seem very likely for anything more
complex than /bin/true ...

> Fat binaries are, IMO, a waste of effort. Just bleeding deal with
> N binaries for N architectures. It just isn't that hard.

They'd be nice in cases where you have programs you can trust not to
gather architecture information before compliation (this includes
manual Makefile editing). The key advantage of fat binaries is ease
of handling and that you can be reasonably sure that foo.i386 is the
same version as foo.sparc.

If you also have fat object files, build procedures are reduced from
make clean, make_all, change_arch, make_clean, make_all (with
assorted prayers that make clean really cleans up properly - anybody
care to check if this is true in little gems like MH or BIND ? :-)
to a simple make_all (Of course, there are some programs already
supporting multi-architecture builds, but they're comparably rare.)

IMHO, fat binaries could be useful and it may be worth exploring that
possibility. If they turn out to be bad, we can always license them
to M$ ;-)

By the way, what are actually the experiences of the NextStep folks ?

- Werner

--
_________________________________________________________________________
/ Werner Almesberger, DI-LRC,EPFL,CH werner.almesberger@lrc.di.epfl.ch /
/_IN_R_133__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.050 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site