ELF binaries and shlibs

The background is that the Linux community is working to support the
ELF binary file format, and that most of this code is available, GPL or
otherwise.

Eric Youngdale wrote in response to a question from me to the Linux intel
binary compatability list:
>
> >Is there an Electronic spec of ELF ?
>
> Not that I am aware of.
>
> >I am under the impression that people think shared libraries will be easier
> >under ELF than currently ?
> >Is this a total misconception ?
>
> Yes, I believe that it will be easier.
>
> >I thought ELF was a file format, or is it that iBSC2 support requires new
> >syscalls (likely) and that ELF indicates an origin (SVID3) and hence is used
> >as an indirect indicator of which syscals are needed.
> >[ I though ELF was hardware independent with extension options for various
> >cpus/systems. ]
>
> Well, ELF is a file format, but it specifies a method to be used for
> dynamic linking. Therefore if a user program needs to call printf, there is
> an entry in the relocation tables indicating where the actual address of printf
> should be patched in. The program loader reads these and performs this linking
> step at run time. In principle, no program binaries should ever contain
> syscalls by themself, they should be calling the stub functions in libc to do
> this (i.e. write, read, etc), so it is the responsibility of libc, not the user
> application to use the appropriate syscall for the local system. The
> specification explicitly states that binary compatibility is to be maintained
> by providing a compatibile set of shared libraries - nothing is explicitly
> mentioned about compatible syscalls.
>
> iBSC2 predates ELF, and there is no specification for the dynamic
> linking. There are specifications for shared libraries which are similar to
> the linux shared libraries prior to the DLL libraries, but the key point is
> that the iBSC2 specification explicitly states that syscalls are to be made via
> the "lcall 7,0" mechanism, and binary compatibility is to be maintained by
> providing a compatible lcall interface.
>
> Even though ELF does not require compatible syscalls, a SVr4 machine
> does implement the iBSC2 syscalls to provide backwards compatibility. Also,
> some of the semantics (i.e. structure definitions, constants, etc) differ from
> linux to SVr4, and it turns out that iBSC2 is much closer to SVr4 than it is to
> linux. Thus while ELF does not directly need the compatible syscalls, it would
> make ELF easier to have them (there would be no need to convert structures in
> libc and so forth).
>
> There are also things in ELF to handle hardware independent things, but
> this is more or less a side issue as far as I am concerned.

I understand that VSTa's binary format is handled largely by execv() and
general executables (file,nm,ld,as,...) it should be as easy to add ELF
support to VSTa as Linux and some of the code framework exists.

Does anybody care about iBSC2 ?
Does anybody have more info on ELF ?

Comments ... ?

regards,
JonT
Received on Thu Sep 2 01:34:58 1993