Re: ELF

But I thought Andrew Valencia said:
>
> [chrisf@sour.sw.oz.au (Christopher Fraser) writes:]
>
> >How do people feel about adpoting ELF as the "standard" executable
> >format in VSTa? ELF is file executable and linking format used in
> >SVR4. It's highly portable, very cool and entirely in the spirit
> >of the festive silly season.
>
> Bah, humbug. a.out is nice, simple, and limited. It keeps languages people
> from doing horrible things. Well, it tries.
>
> Seriously, there are lots of things which would have to be rewritten, for a
> return on investment of 0. This includes boot loader, boot arguments, some
> of the bootup BSS/data sizing, boot process searching, adb, dbsym, as well
> as the exec support in the C library.

Oh sure, ELF doesn't really buy much in the short term and sticking
with a.out has its advantages (it currently works, why fix it etc).
I'm primarily interested in ELF because of its aesthetic qualities
(small, elegant, extensible, etc) although its flexibility and
portability could be beneficial in the longer term. It should
be noted the ease of implementing an ELF loader and my laziness
are purely coincidental :-)

> Don't know what "small" and "big" data segments are. I know that
> R3000/R4000 ports to a.out have been done on various unices, so they can't
> have posed insuperable problems.

They're "one of those MIPS in the name of performance atrocities"
that the MIPS tool-chains use -- clustering of small data items
together so small offsets can be used to access them. Merging them
together is no particular problem, I think they even appear as
merged together data segment if you look at the a.out header bit
of the MIPS ECOFF header. There is information which lost like read
only / sharable data etc, but again it's no great drama.

[ ... ]
> Adding it to lib C to support it for user programs would be an amusing
> exercise. Frankly, at that point libbfd is probably a better approach since
> it handles all the formats. Good byte, lean/mean.

Not necessarily. It's only a little more complicated than an a.out
loader and would be extremely portable. I guess my comments should
been seem from the perspective of wanting to see an much code as
possible made portable across the VSTa platforms (vs keeping the
shared code as simple as possible).

Cheers,

Christopher.
Received on Tue Dec 20 23:50:37 1994