Newsgroups: comp.os.linux.misc
Path: gmd.de!xlink.net!howland.reston.ans.net!EU.net!sun4nl!tudelft.nl!
dutsh7.tudelft.nl!stock
From: st...@dutsh7.tudelft.nl (Robert Stockmann)
Subject: What are ELF binaries?
Message-ID: <stock.761174881@dutsh7.tudelft.nl>
Summary: What are ELF binaries? X11???
Keywords: ELF binaries Linux
Lines:       12
Sender: n...@news.tudelft.nl (UseNet News System)
Nntp-Posting-Host: dutsh7.tudelft.nl
Organization: Delft University of Technology
Date: Sun, 13 Feb 1994 21:28:01 GMT

Hello,

I saw some discussion about COFF and ELF binaries...
I know that COFF support means that you can run SCO binaries
on your linux machine some day....
And that WINE allows you to run MS window binaries some day.....

But I saw in the kernel config.in that ELF is supported...
Well what the hack is it?


Robert Stockmann			<st...@dutsh7.tudelft.nl>

Newsgroups: comp.os.linux.misc
Path: gmd.de!xlink.net!howland.reston.ans.net!paladin.american.edu!
zombie.ncsc.mil!cs.umd.edu!ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: What are ELF binaries?
Message-ID: <CL77H8.A3n@ra.nrl.navy.mil>
Keywords: ELF binaries Linux
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <stock.761174881@dutsh7.tudelft.nl>
Date: Mon, 14 Feb 1994 05:05:31 GMT
Lines: 27

In article <stock.761174...@dutsh7.tudelft.nl> st...@dutsh7.tudelft.nl 
(Robert Stockmann) writes:
>Hello,
>
>I saw some discussion about COFF and ELF binaries...
>I know that COFF support means that you can run SCO binaries
>on your linux machine some day....
>And that WINE allows you to run MS window binaries some day.....
>
>But I saw in the kernel config.in that ELF is supported...
>Well what the hack is it?

	ELF is the object file/executable format used by SVr4.  It uses shared
libraries that are dynamicly linked at runtime that are practically trivial to
build.  The ABI for SVr4 does not specify that the binaries use the same iBSC2
interface as COFF binaries, but in the iBCS2 compliant version of libc that is
under development for COFF/ELF, it turns out to be handy to use the same
interface.

	Technically, COFF is the format used by SVr3, of which SCO is a
variant.  SCO has added a few of their own enhancements, but it is still
basically SVr3.

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Newsgroups: comp.os.linux.misc
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!agate!
library.ucla.edu!csulb.edu!csus.edu!netcom.com!longyear
From: longy...@netcom.com (Alfred Longyear)
Subject: Re: What are ELF binaries?
Message-ID: <longyearCL7G88.I1t@netcom.com>
Keywords: ELF binaries Linux
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
References: <stock.761174881@dutsh7.tudelft.nl>
Date: Mon, 14 Feb 1994 08:14:31 GMT
Lines: 27

st...@dutsh7.tudelft.nl (Robert Stockmann) writes:

>Hello,

>I saw some discussion about COFF and ELF binaries...
>I know that COFF support means that you can run SCO binaries
>on your linux machine some day....
>And that WINE allows you to run MS window binaries some day.....

>But I saw in the kernel config.in that ELF is supported...
>Well what the hack is it?

In the beginning, Dennis Richie created a.out. He looked at it and
said "this was good".

On the second day, x.out was invented. People looked at it and said
"this was good".

On the third day, COFF was invented. People looked at it and said
"this was good".

On the fourth day, ELF was invented. People looked at it and said
"this was good".

ELF is just another format for storing a program on a disk file. It is
used in SVr4. COFF was used in SVr3. X.out was used in S5. A.OUT was used
in S3 and earlier.

Path: gmd.de!newsserver.jvnc.net!darwin.sura.net!howland.reston.ans.net!
math.ohio-state.edu!caen!msuinfo!harbinger.cc.monash.edu.au!uniwa!DIALix!
not-for-mail
From: pe...@melbourne.DIALix.oz.au (Peter Wemm)
Newsgroups: comp.os.linux.misc
Subject: Re: What are ELF binaries?
Date: 14 Feb 1994 18:24:47 +0800
Organization: DIALix Services, Melbourne, Australia.
Lines: 57
Sender: pe...@melbourne.DIALix.oz.au
Message-ID: <2jnjhf$97g$1@melbourne.dialix.oz.au>
References: <stock.761174881@dutsh7.tudelft.nl> <CL77H8.A3n@ra.nrl.navy.mil>
NNTP-Posting-Host: melbourne.dialix.oz.au
Keywords: ELF binaries Linux
X-Newsreader: NN version 6.5.0 #55 (NOV)

e...@tantalus.nrl.navy.mil (Eric Youngdale) writes:
>In article <stock.761174...@dutsh7.tudelft.nl> st...@dutsh7.tudelft.nl 
(Robert Stockmann) writes:
>>Hello,
>>
>>I saw some discussion about COFF and ELF binaries...
>>I know that COFF support means that you can run SCO binaries
>>on your linux machine some day....
>>And that WINE allows you to run MS window binaries some day.....
>>
>>But I saw in the kernel config.in that ELF is supported...
>>Well what the hack is it?

>	ELF is the object file/executable format used by SVr4.  It uses shared
>libraries that are dynamicly linked at runtime that are practically trivial to
>build.  The ABI for SVr4 does not specify that the binaries use the same iBSC2
>interface as COFF binaries, but in the iBCS2 compliant version of libc that is
>under development for COFF/ELF, it turns out to be handy to use the same
>interface.

>	Technically, COFF is the format used by SVr3, of which SCO is a
>variant.  SCO has added a few of their own enhancements, but it is still
>basically SVr3.

>-Eric

The nice thing about ELF is that it's extensible..  Theoretically,
extra types of data can be added internally whithout breaking
everything.  It's designed from the ground up with dynamic linking in
mind.  Despite the fact that it was first used in SVR4, I think many
people like the design.  Sure, it's harder to program for and support
within assemblers and linkers, etc, but I think it's worth it.  

However, DWARF is another thing.. The very nature of an extensible
file format allows the choice of whatever debugging format tickles
your fancy...  The DWARF debugging format is not very well supported.
There's rudimentry within GCC, but the G++ implementation is not up to
scratch.  This is especially messed up because SUN chose to use the
old STABS debugging codes within their ELF executables..  HP use their
own debugging format within ELF, and so on.  DWARF is rather complex
(but quite rich in it's descriptive capability) and *very* hard to
program for.

What I like about the SVR4 i386 ABI is that the defined interface is
at the link-library level.  The ABI defines the library calls and
their arguments only.  The actual system call interface is free-form.
You can emulate or even translate the linker-level functions into an
alternative system call scheme, as was the case with the ELF support
on Linux.  That's why ELF support was done long before COFF - it was
orders of magnitude easier to get running...

Just my $0.02...  (and not that I'm an expert on the subject either..)

-Peter
-- 
Peter Wemm <pe...@DIALix.oz.au> - NIC Handle: PW65 - The keeper of "NN"
      "My computer is better than your computer" - Anonymous
  (Overheard, shortly after the creation of the second computer....)

Newsgroups: comp.os.linux.misc
Path: gmd.de!newsserver.jvnc.net!news2.cac.psu.edu!news.pop.psu.edu!ra!
tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: What are ELF binaries?
Message-ID: <CL879q.ELD@ra.nrl.navy.mil>
Keywords: ELF binaries Linux
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <stock.761174881@dutsh7.tudelft.nl> <CL77H8.A3n@ra.nrl.navy.mil> 
<2jnjhf$97g$1@melbourne.dialix.oz.au>
Date: Mon, 14 Feb 1994 17:58:37 GMT
Lines: 39

In article <2jnjhf$97...@melbourne.dialix.oz.au> pe...@melbourne.DIALix.oz.au 
(Peter Wemm) writes:
>What I like about the SVR4 i386 ABI is that the defined interface is
>at the link-library level.  The ABI defines the library calls and
>their arguments only.  The actual system call interface is free-form.
>You can emulate or even translate the linker-level functions into an
>alternative system call scheme, as was the case with the ELF support
>on Linux.  That's why ELF support was done long before COFF - it was
>orders of magnitude easier to get running...

	Indeed this is true.  The only tricky part is the dynamic linker.  The
original abi package would actually use a hacked version of nm to locate the
symbols in the linux C library.  Unfortunately this had a number of flaws,
mainly that things like error numbers and so forth are a little different
between SVr4 and linux, and this resulted in strange behavior in some cases.  I
basically decided last summer that this ABIlib was a dead end approach which
would be difficult to get working properly.  The new FILE structure in the
newer linux-libc also broke the ABIlib.

	The current effort uses the same iBCS2 interface that the COFF binaries
use.  I did not need to do this, of course, but this way the error numbers,
signal numbers, etc, etc, are guaranteed to be correct all the way through.
Even then though, apparently SVr4 does more networking stuff in user mode than
linux does.  As it turns out, there is someone who has had some success getting
TCP/IP working with Wyse binaries, and I think I can tap into this kernel code
and provide networking for ELF binaries.  Again, the advantage of using the
lcall 7,0 interface instead of the int 0x80 interface is that with the lcall
7,0 any error conditions get the error numbers converted back to the ibcs2
numbers. 

	Anyone who wants to try SVr4 binaries under linux (who has not
previously contacted me) can try the new approach (for one thing, I need people
to try the library and locate bugs for me.  I think it will work more smoothly
in the long run, and ultimately I think that there will be support for binaries
that use TCP/IP and X11.  No TCP in the current version, however.

-Eric
-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Newsgroups: comp.os.linux.misc
Path: gmd.de!newsserver.jvnc.net!darwin.sura.net!howland.reston.ans.net!
europa.eng.gtefsd.com!library.ucla.edu!csulb.edu!csus.edu!netcom.com!longyear
From: longy...@netcom.com (Alfred Longyear)
Subject: Re: What are ELF binaries?
Message-ID: <longyearCL8DtA.12r@netcom.com>
Keywords: ELF binaries Linux
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
References: <stock.761174881@dutsh7.tudelft.nl> <CL77H8.A3n@ra.nrl.navy.mil> 
<2jnjhf$97g$1@melbourne.dialix.oz.au>
Date: Mon, 14 Feb 1994 20:19:53 GMT
Lines: 30

pe...@melbourne.DIALix.oz.au (Peter Wemm) writes:

>e...@tantalus.nrl.navy.mil (Eric Youngdale) writes:

>>	ELF is the object file/executable format used by SVr4.  It uses shared
>>libraries that are dynamicly linked at runtime that are practically trivial to
>>build.  The ABI for SVr4 does not specify that the binaries use the same iBSC2
>>interface as COFF binaries, but in the iBCS2 compliant version of libc that is
>>under development for COFF/ELF, it turns out to be handy to use the same
>>interface.

>>	Technically, COFF is the format used by SVr3, of which SCO is a
>>variant.  SCO has added a few of their own enhancements, but it is still
>>basically SVr3.

>You can emulate or even translate the linker-level functions into an
>alternative system call scheme, as was the case with the ELF support
>on Linux.  That's why ELF support was done long before COFF - it was
>orders of magnitude easier to get running...

Because Eric had no need to run COFF executables. His system used ELF
as the object file format, not COFF. I could give you a lot of
other reasons, but that is the "real" reason. People extend Linux because
they have a need. If there is no need, then there is no reason.

And actually, COFF is a simpler file format than ELF. It is/was easier
to implement than ELF. Especially considering that ELF was the first
non-a.out format used and it required the restructuring of the exec.c
module within the kernel.

Newsgroups: comp.os.linux.misc
Path: gmd.de!newsserver.jvnc.net!news2.cac.psu.edu!news.pop.psu.edu!ra!
tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: What are ELF binaries?
Message-ID: <CL8KEI.y7@ra.nrl.navy.mil>
Keywords: ELF binaries Linux
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <CL77H8.A3n@ra.nrl.navy.mil> <2jnjhf$97g$1@melbourne.dialix.oz.au> 
<longyearCL8DtA.12r@netcom.com>
Date: Mon, 14 Feb 1994 22:42:17 GMT
Lines: 28

In article <longyearCL8DtA....@netcom.com> longy...@netcom.com 
(Alfred Longyear) writes:
>>You can emulate or even translate the linker-level functions into an
>>alternative system call scheme, as was the case with the ELF support
>>on Linux.  That's why ELF support was done long before COFF - it was
>>orders of magnitude easier to get running...
>
>Because Eric had no need to run COFF executables. His system used ELF
>as the object file format, not COFF. I could give you a lot of
>other reasons, but that is the "real" reason. People extend Linux because
>they have a need. If there is no need, then there is no reason.

	Quite right.  We have SVr4 at work, so ELF was of more interest.
I do not have access to SCO or any other COFF based system

>And actually, COFF is a simpler file format than ELF. It is/was easier
>to implement than ELF. Especially considering that ELF was the first
>non-a.out format used and it required the restructuring of the exec.c
>module within the kernel.

	It was worse than that.  I needed to work on the memory manager to
support mmap - previously mmap was basically limited to things like /dev/mem
which was used by the X server to get to it's video memory.

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

Newsgroups: comp.os.linux.misc
Path: gmd.de!xlink.net!howland.reston.ans.net!cs.utexas.edu!uunet!wyvern!
taylor.wyvern.com!mark
From: m...@taylor.wyvern.com (Mark A. Davis)
Subject: Re: What are ELF binaries?
Organization: Lake Taylor Hospital Computer Services
Date: Tue, 15 Feb 1994 03:23:55 GMT
Message-ID: <1994Feb15.032355.26760@taylor.wyvern.com>
References: <CL77H8.A3n@ra.nrl.navy.mil> <2jnjhf$97g$1@melbourne.dialix.oz.au> 
<longyearCL8DtA.12r@netcom.com> <CL8KEI.y7@ra.nrl.navy.mil>
Keywords: ELF binaries Linux
Lines: 22

e...@tantalus.nrl.navy.mil (Eric Youngdale) writes:

>In article <longyearCL8DtA....@netcom.com> longy...@netcom.com 
(Alfred Longyear) writes:
>>>on Linux.  That's why ELF support was done long before COFF - it was
>>>orders of magnitude easier to get running...
>>
>>Because Eric had no need to run COFF executables. His system used ELF
>>as the object file format, not COFF. I could give you a lot of
>>other reasons, but that is the "real" reason. People extend Linux because
>>they have a need. If there is no need, then there is no reason.

>	Quite right.  We have SVr4 at work, so ELF was of more interest.
>I do not have access to SCO or any other COFF based system

And yet most of the most popular commercial Unix software for x86 is only
available for SCO (COFF).....  

-- 
  /--------------------------------------------------------------------------\
  | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
  | Sys.Administrator|  Computer Services   | m...@taylor.wyvern.com   .uucp |
  \--------------------------------------------------------------------------/

Path: gmd.de!xlink.net!howland.reston.ans.net!gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Robert Sanders)
Newsgroups: comp.os.linux.misc
Subject: Re: What are ELF binaries?
Keywords: ELF binaries Linux
Message-ID: <138914@hydra.gatech.EDU>
Date: 15 Feb 94 06:24:43 GMT
References: <CL77H8.A3n@ra.nrl.navy.mil> <2jnjhf$97g$1@melbourne.dialix.oz.au> 
<longyearCL8DtA.12r@netcom.com> <CL8KEI.y7@ra.nrl.navy.mil> 
<1994Feb15.032355.26760@taylor.wyvern.com>
Sender: n...@prism.gatech.EDU
Lines: 25

m...@taylor.wyvern.com (Mark A. Davis) writes:

>e...@tantalus.nrl.navy.mil (Eric Youngdale) writes:

>>	Quite right.  We have SVr4 at work, so ELF was of more interest.
>>I do not have access to SCO or any other COFF based system

>And yet most of the most popular commercial Unix software for x86 is only
>available for SCO (COFF).....  

>  | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |

Well, folks, we've found a new net-grepper.  Put 'ELF' and 'COFF' in
your .sig today and watch the Mark A. Davis followup daemon thrash
itself to pieces.

Calm down, Mark.  COFF and ELF support seem to be progressing at about
the same pace.  For example, COFF Perl runs, and Perl uses most everything
Unix has to offer...

--
 _g,  '96 --->>>>>>>>>>   gt81...@prism.gatech.edu  <<<<<<<<<---  CompSci  ,g_
W@@@W__        |-\      ^        | disclaimer:  <---> "Bow before ZOD!" __W@@@W
W@@@@**~~~'  ro|-<ert s/_\ nders |   who am I???  ^  from Superman  '~~~**@@@@W
`*MV' hi,ocie! |-/ad! /   \ss!!  | ooga ooga!!    |    II (cool)!         `VW*'

Newsgroups: comp.os.linux.misc
From: ja...@purplet.demon.co.uk (Mike Jagdis)
Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!uknet!demon!purplet!jaggy
Subject: Re: What are ELF binaries?
Organization: FidoNet node 2:252/305 - The Purple Tentacle, Reading
Date: Tue, 15 Feb 1994 23:48:00 +0000
Message-ID: <520.2D62A074@purplet.demon.co.uk>
Sender: use...@demon.co.uk
Lines: 13

* In message <1994Feb15.032355.26...@taylor.wyvern.com>, Mark A. Davis said:

MD> >       Quite right.  We have SVr4 at work, so ELF was of more interest.
MD> >I do not have access to SCO or any other COFF based system

MD> And yet most of the most popular commercial Unix software
MD> for x86 is only available for SCO (COFF).....

Eric may only have SVR4 but others only have SVR3/SCO. Don't worry, the SCO 
side is coming along just fine too...

                                Mike

Newsgroups: comp.os.linux.misc
Path: gmd.de!newsserver.jvnc.net!news.edu.tw!news!nctuccca.edu.tw!
howland.reston.ans.net!cs.utexas.edu!uunet!wyvern!taylor.wyvern.com!mark
From: m...@taylor.wyvern.com (Mark A. Davis)
Subject: Re: What are ELF binaries?
Organization: Lake Taylor Hospital Computer Services
Date: Wed, 16 Feb 1994 14:41:59 GMT
Message-ID: <1994Feb16.144159.7343@taylor.wyvern.com>
References: <CL77H8.A3n@ra.nrl.navy.mil> <2jnjhf$97g$1@melbourne.dialix.oz.au> 
<longyearCL8DtA.12r@netcom.com> <CL8KEI.y7@ra.nrl.navy.mil> 
<1994Feb15.032355.26760@taylor.wyvern.com> <138914@hydra.gatech.EDU>
Keywords: ELF binaries Linux
Lines: 43

gt81...@prism.gatech.EDU (Robert Sanders) writes:

>m...@taylor.wyvern.com (Mark A. Davis) writes:

>>e...@tantalus.nrl.navy.mil (Eric Youngdale) writes:

>>>	Quite right.  We have SVr4 at work, so ELF was of more interest.
>>>I do not have access to SCO or any other COFF based system

>>And yet most of the most popular commercial Unix software for x86 is only
>>available for SCO (COFF).....  

>Well, folks, we've found a new net-grepper.  Put 'ELF' and 'COFF' in
>your .sig today and watch the Mark A. Davis followup daemon thrash
>itself to pieces.

>Calm down, Mark.  COFF and ELF support seem to be progressing at about
>the same pace.  For example, COFF Perl runs, and Perl uses most everything
>Unix has to offer...

Hey, I can't calm down about this issue!  I have been pushing it into the 
spotlight for a long time now.  I KNOW how important it is to the future of
Linux.   Until recently, many hackers could care less about COFF and binary
compatibility with SCO, usually because they didn't understand what it would
do for Linux.  I like to think that I have helped heighten awareness of
the issues..... (maybe a little?  at least shown enthusiasm?)

I admit, I can be a "followup daemon" on this subect sometimes :)  :)
At least I'm an artificially intelligent, interactive daemon!!

echo "Mark A. Davis now signing off.... "
for proc in `ps -a | fgrep "MarkDaemon" | awk '{print $1}'
 do kill $proc ; sleep 4 ; kill -9 $proc
 echo "Ouch!!!"
done
echo "Mark A. Davis daemon is now dead!  Rejoice!!"


-- 
  /--------------------------------------------------------------------------\
  | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
  | Sys.Administrator|  Computer Services   | m...@taylor.wyvern.com   .uucp |
  \--------------------------------------------------------------------------/