evan@telly.on.ca (Evan Leibovitch) (03/05/91)
This question is about
"elf" (the format of executable files under System V release 4)
and
"coff" (the format now used in Release 3.2)
At the recent meeting of Uniforum Toronto, we received a fairly detailed
description of Release 4. It was mentioned that Release 4 will properly
execute coff-format files, even though they prefer elf (through an
emulator?).
As I understand it, however, the elf-format files produced on Release 4
systems will not run on 3.2 systems. This means that someone wanting to
produce software for the 386 UNIX market cannot rely totally on the
Release 4 software to develop software for the entire marketplace, since
SCO in its wisdom :-P has decided not to bother with Release 4.
Or does it mean something else?
Is there indeed no backwards compatability in the R4 compiler? Although
the obvious answer is to buy SCO because binaries compiled on it will
run on all UNIX vendors' current releases, I'm very hesitant to buy
software mainly because it's the lowest common denominator.
So what are the other choices? Which of these options is best? Are they
even possible? Are there other options?
- If you have a present copy of Interactive/Dell/ESIX R3.2, can you hang
onto the 3.2 software development set when you upgrade to R4? Then you
could load the 3.2 compiler, which should run fine under R4 (though the
libraries will still be the old ones).
- Are there any plans for SCO 3.2 to support elf? Considering the
direction the company is going (back to the Xenix philosophy), it
seems that such a move would not be in the company's strategic
interest. But we can hope...
- Use gcc. Can it possibly be built to use the R4 libraries, while
having a run-time switch to produce either coff or elf?
- Will it be economically worthwhile for a commercial compiler vendor to
offer a development set with cross-compiling options?
A larger question is "what are the advantages of compiling for elf when
coff is more portable?" What features of R4 *require* something to be
compiled with elf?
Thanks for your patience. And sorry for the pun.
--
Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario
evan@telly.on.ca / uunet!attcan!telly!evan / (416) 452-0504
Vanilla Ice is a few cubes short of a full tray...pjh@mccc.edu (Pete Holsberg) (03/05/91)
In article <27D314DF.1D4E@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes:
=This question is about
= "elf" (the format of executable files under System V release 4)
=and
= "coff" (the format now used in Release 3.2)
You may be interested to know that elves will be executed by AT&T SV/386
R3.2.2. Or, you may not. ;-)
Pete
--
Prof. Peter J. Holsberg Mercer County Community College
Voice: 609-586-4800 Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690
Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91mburg@unix386.Convergent.COM (Mike Burg) (03/06/91)
In article <27D314DF.1D4E@telly.on.ca>, evan@telly.on.ca (Evan Leibovitch) writes: [text deleted] I don't think that either "camp" of the PC UNIX producers (AT&T and SCO) want to supply detail compatiblity for each other. [And with some older versions of their own OS! ;-) ;-)]. They want you to use their product and (in case of developers) to produce for their product. > Is there indeed no backwards compatability in the R4 compiler? Although > the obvious answer is to buy SCO because binaries compiled on it will > run on all UNIX vendors' current releases, I'm very hesitant to buy > software mainly because it's the lowest common denominator. The only backwards compability for R4 cc is the ability to execute COFF binaries, and convert COFF to ELF format (i.e. ld, size, dis, etc will all accept COFF but will do a internal convertion to ELF). > > So what are the other choices? Which of these options is best? Are they > even possible? Are there other options? > > - If you have a present copy of Interactive/Dell/ESIX R3.2, can you hang > onto the 3.2 software development set when you upgrade to R4? Then you > could load the 3.2 compiler, which should run fine under R4 (though the > libraries will still be the old ones). I've heard this can be done. All of the SVR4 compiler is located in /usr/ccs with links to /usr/bin. However, there are some libraries left in /usr/lib you'll have to watch out for. > > - Are there any plans for SCO 3.2 to support elf? Considering the > direction the company is going (back to the Xenix philosophy), it > seems that such a move would not be in the company's strategic > interest. But we can hope... It will be interesting to see if they do. I highly doubt it if they do anything about ELF - they have stated on record that their "users" don't have a demand for it ("SVR4 features"). > - Use gcc. Can it possibly be built to use the R4 libraries, while > having a run-time switch to produce either coff or elf? I've tried using GCC-1.37.1 (no Gnu ld or GAS) on SVR4. It's fine to compile most things, but however it will gack on the #if machine(i386) directives commonly found in /usr/include/sys files. Anyone else have any luck? 1.38, 1.39? All of the SVR4 libraries are in ELF format, plus the functions are compiled for a SVR4 enviroment (i.e. a lot of system calls have been extended in SVR4 - see below). GCC would have to be taught about a 3.2 enviroment verus a R4 one - which libraries, include files, binary formats to use. You'd still need the 3.2 libraries. > - Will it be economically worthwhile for a commercial compiler vendor to > offer a development set with cross-compiling options? Well, it depends on how large of a demand there is for producing COFF binaries on a SVR4, SCO binaries on SVR4/3.2, or ELF under SCO. It's like anything else - if there's money to be made...... My personal opinion is develop/compile it on the platform the product is intended for. You'll won't have the hassiles of compability. However, this can only be done if you have the resources. As far as compiling for R3.2 under R4 - AT&T or any other AT&T Unix vendor could produce a 3.2 development system that would work and be installed "cleanly" in R4. It just a matter of having the install scripts place the package into another directory tree, and having the utilities make use of the altered layout (namely 'cc'). > A larger question is "what are the advantages of compiling for elf when > coff is more portable?" What features of R4 *require* something to be > compiled with elf? The two big advantages with ELF is dynamic libraries (space saving) and the ability to directly map the executable into memory without having to do page aligment from disk (load and page fault time savings). Both features make heavy use of mmap(). The other features are pretty minor (for COFF verus ELF): - clean binary information extraction across different machine architectures, "self describing" binary sections, read only (const char */int/etc) data areas. Once the kernel has loaded the binary, every system call acts the same for COFF or ELF - the expection is for Xenix binaries. As for the question of what about SVR3.2 and SVR4 common system calls that have different arguments or different argument formats work together. (i.e. stat in 3.2 has a 16-bit inode file, while SVR4 has a 32-bit plus extra fields). Some of SVR4 system calls are really renamed - take a look at /usr/include/sys/stat.h. When you call stat() you are really calling _xstat with a version number as one of it's arguments. It is possible for a ELF binary to call a old SVR3.2 old format system call, while a COFF binary can call a new SVR4 one. > Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario -- ---------------------------------- Michael Burg - Unisys/Convergent Corp. Unix Intel Platforms Division San Jose Phone: (408) 456-5934 UUCP: uunet!pyramid!ctnews!unix386.Convergent.com!mburg
sef@kithrup.COM (Sean Eric Fagan) (03/06/91)
In article <27D314DF.1D4E@telly.on.ca> evan@telly.on.ca (Evan Leibovitch) writes: >Is there indeed no backwards compatability in the R4 compiler? Not as far as I know. Not terribly surprising: I don't believe that ISC (actually, anyone but SCO) lets you develop for previous releases (e.g., xenix, '286). (That comment, which is quite possibly wrong, is based soley on comments I'd seen here previously. If I'm wrong, I apologise in advance...) >Although >the obvious answer is to buy SCO because binaries compiled on it will >run on all UNIX vendors' current releases, I'm very hesitant to buy >software mainly because it's the lowest common denominator. "Buy SCO: The Lowest Common Denominator." I don't think I should comment any further on that 8-). >So what are the other choices? Which of these options is best? Are they >even possible? Are there other options? > >- If you have a present copy of Interactive/Dell/ESIX R3.2, can you hang > onto the 3.2 software development set when you upgrade to R4? Then you > could load the 3.2 compiler, which should run fine under R4 (though the > libraries will still be the old ones). I would be very surprised if this wouldn't work. You would need some way of getting all of the binaries on, of course, but once that would done, it should work. Note that you would probably want to use gencc to make a program that will run in a different location (so as not to collide with the 4.0 devsys). >- Use gcc. Can it possibly be built to use the R4 libraries, while > having a run-time switch to produce either coff or elf? There are two issues here: one is making the compiler spit out coff/elf assembly, and the other is having the rest of the devsys deal with it (as, ld, libraries, etc.). gcc currently doesn't have any libraries released (although I think gnulibc is in beta or late alpha?), but, since you've got all the sources, you can (theoretically) make it work any way you want. I have, myself, built gcc and gas to deal with COFF; all that's needed, besides that, are linkers and libraries. >A larger question is "what are the advantages of compiling for elf when >coff is more portable?" What features of R4 *require* something to be >compiled with elf? Anything that is new for 4.0 could, conceivably, need to be compiled as an ELF binary. (This is because the kernel will differentiate between the various binary types, and the syscall numbers could be different.) Also, the dynamic-linking shared libraries need ELF (since the object files for the libraries is ELF, and the library routines to do this expect ELF). Other than all that (8-)), I don't see any problems. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
johnk@opel.COM (John Kennedy) (03/06/91)
The ELF incompatibility issue doesn't seem to be just with R4. My client bought some 60 AT&T 6386/25s with SVr3.2.2, whose compiler generates ELF format. At the same time, all the Driver.o's in the kernel were in the COFF format. If we installed our own drivers, compiling in the ELF format, the kernel building utilities choked. We had to get a AT&T to provide us with a COFF-based Software Development System to link our drivers. John -- John Kennedy johnk@opel.COM Second Source, Inc. Annapolis, MD
james@bigtex.cactus.org (James Van Artsdalen) (03/08/91)
In <6405@unix386.Convergent.COM>, mburg@unix386.Convergent.COM (Mike Burg) wrote: | - Use gcc. Can it possibly be built to use the R4 libraries, while | having a run-time switch to produce either coff or elf? gcc produces assembler source. The format of the executable depends on that format the linker produces, not the assembly source. So if you use the SysVr4 linker, you get ELF output. > I've tried using GCC-1.37.1 (no Gnu ld or GAS) on SVR4. It's fine to > compile most things, but however it will gack on the #if machine(i386) > directives commonly found in /usr/include/sys files. Anyone else have > any luck? 1.38, 1.39? gcc 1.39 has a target "i386v4". It also has a special version of of fixincludes called "fixincludes-V4" that gets rid of the #machine nonsense. > The two big advantages with ELF is dynamic libraries (space saving) I still don't like the dynamic libraries. It makes executables slower to start (exec(2) time), and more importantly, the code in a shared dynamic library is worse/slower than code in a non-shared library. In SysVr3 you had to make changes to the source to make a shared library, but at least there wasn't as big a performance penalty. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
ts@cup.portal.com (Tim W Smith) (03/11/91)
Just say "to hell with it" and develop your product under DOS. Since everyone has DOS emulation, you can then run under AT&T or SCO. Tim Smith
staceyc@sco.COM (Stacey Campbell) (03/12/91)
In article <6405@unix386.Convergent.COM> mburg@unix386.Convergent.COM (Mike Burg) writes: >I don't think that either "camp" of the PC UNIX producers (AT&T and SCO) >want to supply detail compatiblity for each other. From elsewhere on the net; SANTA CRUZ, CALIFORNIA, U.S.A., 1991 FEB 28 (NB) -- The Santa Cruz Operation, the largest supplier of Unix on Intel microprocessors, says it will certify that its software runs on AT&T's 80386-based computers. The agreement says that SCO will dedicate special test facilities for the AT&T 6386SX/EL, 6386/25 and 6386E/33 WorkGroup Systems. Also, the company will work with AT&T staff to ensure compatibility with AT&T networking and terminal products. AT&T sells an Intel-based Unix of its own: System V/386. SCO's Unix, however, leads the market and includes enhancements not included in AT&T's version, such as the Open Desktop user interface and a range of device drivers. -- Stacey Campbell Internet: staceyc@sco.com UUCP: {uunet,ucscc,att,sq,altos,lotus,sun,microsoft}!sco!staceyc
mburg@unix386.Convergent.COM (Mike Burg) (03/13/91)
In article <10719@scolex.sco.COM>, staceyc@sco.COM (Stacey Campbell) writes: # In article <6405@unix386.Convergent.COM> mburg@unix386.Convergent.COM (Mike Burg) writes: # >I don't think that either "camp" of the PC UNIX producers (AT&T and SCO) # >want to supply detail compatiblity for each other. # From elsewhere on the net; # SANTA CRUZ, CALIFORNIA, U.S.A., 1991 FEB 28 (NB) -- The Santa Cruz # Operation, the largest supplier of Unix on Intel microprocessors, # says it will certify that its software runs on AT&T's 80386-based # computers. [Text deleted about special test group formed] # AT&T sells an Intel-based Unix of its own: System V/386. SCO's # Unix, however, leads the market and includes enhancements not # included in AT&T's version, such as the Open Desktop user interface # and a range of device drivers. Okay, so SCO is verifying that their OS runs on AT&T PC's (and consider they are basicly just another clone...) And providing support for Open Desktop. But the one context of the original message was abourt vendor support for _binary_ ABI's.. - i.e. What is SCO going to do about ELF? -- ---------------------------------- Michael Burg - Unisys/Convergent Corp. Unix Intel Platforms Division San Jose Phone: (408) 456-5934 UUCP: uunet!pyramid!ctnews!unix386.Convergent.com!mburg
sef@kithrup.COM (Sean Eric Fagan) (03/13/91)
In article <6765@unix386.Convergent.COM> mburg@unix386.Convergent.COM (Mike Burg) writes: >But the one context of the original message was abourt vendor support >for _binary_ ABI's.. - i.e. What is SCO going to do about ELF? While I know nothing about what SCO is going to do about ELF (really, truly, and honestly; I don't really care, either 8-)), I would like to point out that the two issues (ELF and the ABI) are mutually irrelevant. That is, the ABI specifies a whole bunch of things, including the COFF file format. As a result, if you want to conform to the ABI, you get to use COFF. For SysVr4, I think they just end up with different system-call entry points for each file format (that is, ELF goes through one table, COFF through another, x.out through yet another, etc.), which I must admit is a very nice thing. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
mjl@lccma.bos.locus.com (Mike Leibensperger) (03/14/91)
In article <1991Mar13.095416.7172@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >While I know nothing about what SCO is going to do about ELF (really, truly, >and honestly; I don't really care, either 8-)), I would like to point out >that the two issues (ELF and the ABI) are mutually irrelevant. That is, the >ABI specifies a whole bunch of things, including the COFF file format. As a >result, if you want to conform to the ABI, you get to use COFF. True, ELF != ABI. The whole point of the ABI is to allow the development of shrink-wrapped off-the-shelf Unix software. There was a lot of brouhaha in the trade press recently about SCO, Intel, et. al. agreeing to an ABI so they can embark on a big applications push. But the truly *alarming* thing is this: If SVR4 development systems have no COFF, and if Sean's assertion that SVR4 actually uses different syscall numbers depending on linker format, then you can't use SVR4 to develop ABI conforming programs!!! What's the scam here, AT&T? This is terribly inconvenient for applications developers. I have a bad feeling that some sleazoid somewhere is going to rake in a lot of ill-gotten bucks thanks to this inconvenience. Can somebody out there fill us in on the politics of this whole situation? What is the fate of the ABI? What linker format is Intel's SVR4 going to use? SCO's? Interactive's? etc. etc. Sigh.... mjl -- Michael J. Leibensperger <mjl@locus.com> "None are so deeply enslaved Locus Computing Corp./Boston as those who falsely believe 25 Burlington Mall Road they are free." Burlington MA 01803, (617)229-4980 x169 -- J. W. von Goethe
rcd@ico.isc.com (Dick Dunn) (03/14/91)
To clarify some points which seemed confused in the discussion between Sean Fagan and Mike Burg: The terms "BCS" and "ABI" refer to different animals, although they're both of the same species (a definition of a "system inter- face for compiled application programs"). Background: SVID == System V Interface Definition - definition of the programs, system calls, libraries, etc. BCS == Binary Compatibility Specification: This is the V.3.2 animal; it refers to SVID 2nd edition; COFF spoken here. COFF == Common Object File Format. BCS is undergoing extensive revision (mostly extension) to cover things not present in the original version. You'll hear this work called "BCS2". ABI == Application Binary Interface: This is the V.4 animal; it refers to SVID 3rd edition; ELF is a part of it. ELF == Executable and Linking Format. However, note that V.4 will provide support for BCS (and there- fore can run COFF programs). I don't know, but I would not expect support for ELF on V.3.2 systems--why retrofit it, rather than just go to V.4? Summary: BCS V.3.2 COFF SVID 2 ABI V.4 ELF SVID 3 -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
dyson@cbnewsk.att.com (john.s.dyson) (03/14/91)
In article <1991Mar14.001906.29397@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: > To clarify some points which seemed confused in the discussion between Sean > Fagan and Mike Burg: The terms "BCS" and "ABI" refer to different animals, > although they're both of the same species (a definition of a "system inter- > face for compiled application programs"). > > Background: SVID == System V Interface Definition - definition of the > programs, system calls, libraries, etc. > > BCS == Binary Compatibility Specification: This is the V.3.2 animal; it > refers to SVID 2nd edition; COFF spoken here. COFF == Common Object File > Format. BCS is undergoing extensive revision (mostly extension) to cover > things not present in the original version. You'll hear this work called > "BCS2". > > ABI == Application Binary Interface: This is the V.4 animal; it refers to > SVID 3rd edition; ELF is a part of it. ELF == Executable and Linking > Format. However, note that V.4 will provide support for BCS (and there- > fore can run COFF programs). I don't know, but I would not expect support > for ELF on V.3.2 systems--why retrofit it, rather than just go to V.4? > > Summary: > BCS V.3.2 COFF SVID 2 > ABI V.4 ELF SVID 3 > -- > Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 > ...But is it art? Note that at least AT&T SVR3.2.2 can run ELF and a Software generation system is available that produces ELF files for SVR3.2.2. I do not know if the SVR3.2.2 support is a subset or not though. The ANSI compiler in fact is an ELF format file. The tools such as dis, etc can convert COFF to ELF automatically. John Dyson inuxy.att.com
junk1@cbnews.att.com (eric.a.olson) (03/14/91)
In article <1991Mar14.001906.29397@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >Format. However, note that V.4 will provide support for BCS (and there- >fore can run COFF programs). I don't know, but I would not expect support >for ELF on V.3.2 systems--why retrofit it, rather than just go to V.4? > >Summary: > BCS V.3.2 COFF SVID 2 > ABI V.4 ELF SVID 3 The AT&T SDS 4.1.6 Software Development Package generates COFF output files. The AT&T SCDE 5.0/3 Package generates ELF output files, and can accept COFF .o files as input, with conversion performed internally. AT&T SVR3.2.2 and above systems can execute ELF format executables. SCDE 5.0/3 is available for SVR3.2 and may be installed in a 'transitional' mode which allows both compiler environments on a machine at the same time. In addition, SCDE 5.0 allows a choice of three modes: K&R, ANSI, and a mode which allows ANSI syntax and preserves K&R semantics in the areas where the semantics would be different (mostly involving promotion and unsigned comparison). eric olson eao@mvucl.att.com at&t bell labs, haverhill, ma. c