Re: ELF

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

>Seriously though, adopting ELF seems like a Good Thing. If nothing
>else it would most of the executable format handling code be machine
>independent, but there are lots of other good reasons (I'd started
>running into a.out limitations in my MIPS port, like no support
>for multiple "small" and "big" data segments etc, and adding ELF
>was much easier and more elegant than ECOFF).

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.

>Reading over the binutils-2.5.1 documentation makes me think that
>it's quite stable on intel and sparc platforms (the Linux people
>seem to be using it quite a lot). I haven't had any problems on
>the MIPSen yet. I'm not sure about 68k.

Yes, but you'll also find that the 2.X gas is moving into the same size as
the 1.X GNU C compiler itself. This "lcc" thing looks promising, IMHO.
I want the lean/mean language tools option.

>libc support would also be pretty easy. The machine dependent bit
>should be limited to some header checks (architecture, endianess
>etc). The only manditory change would be extending struct mapfile
>to allow an arbitrary number of mappings.

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.

>where if m_filesz < m_memsz the rest of the mapping is ZFOD, which
>is how ELF represents such things. I would be tempted to keep the
>prsent ZFOD-flag style interface and have the libc code work out
>which bits of the mapping are ZFOD and which are demand paged and
>do seperate mapseg entries for them.

I agree on your ZFOD perspective.

As for the servers and such, I think converting executable formats would
cost time better spent in other areas. Networking, remote services, and so
forth. Need to hear more about this R3000 "big/small data" thing, though.
I hope this isn't another one of those MIPS "in the name of performance"
atrocities. Next thing you know we'll be looking at page coloring to cover
their direct-mapped cache.

Hmmm, perhaps I'd better add a disclaimer here that these are only my own
personal opinions! :-)

                                                Andy
Received on Tue Dec 20 15:17:46 1994