bediger@isis.cs.du.edu (bruce allen ediger) (04/30/91)
I'm beginning to understand why one would prefer an executable file format like Mach-O or COFF. What I don't understand is why we need two of them. It strikes me that COFF headers and Mach-O load commands contain similar if not identical information about the executables layout on disk and in memory. Why not just use COFF?
mike@yalla.tuwien.ac.at (Michael K. Gschwind) (04/30/91)
In article <1991Apr30.054735.7606@mnemosyne.cs.du.edu> bediger@isis.cs.du.edu (bruce allen ediger) writes:
I'm beginning to understand why one would prefer an executable file format
like Mach-O or COFF. What I don't understand is why we need two of them.
It strikes me that COFF headers and Mach-O load commands contain similar if
not identical information about the executables layout on disk and in
memory. Why not just use COFF?
Mach-O is more powerful, as far as I can remember. Mach-O allows you
to set up more than one thread (?) and you can also store core dumps
in Mach-O! Mach-O is more universal, it allows you to assign start
values to registers (does this work in COFF as well? - I dunno.)
COFF != COFF, there are many variations, since COFF allows some
sections of a COFF file to be used by different vendors. There is
ECOFF (DecStations), COFF for Apollos, which stores all debugging info
in one of the optional sections,...
So if COFF isn't that compatible anyway, why not start from scratch
and have a clean start?
bye,
mike
Michael K. Gschwind, Dept. of VLSI-Design, Vienna University of Technology
mike@vlsivie.tuwien.ac.at 1-2-3-4 kick the lawsuits out the door
mike@vlsivie.uucp 5-6-7-8 innovate don't litigate
e182202@awituw01.bitnet 9-A-B-C interfaces should be free
Voice: (++43).1.58801 8144 D-E-F-O look and feel has got to go!
Fax: (++43).1.569697 guy@auspex.auspex.com (Guy Harris) (05/02/91)
>and you can also store core dumps in Mach-O! COFF's replacement in S5R4, ELF, also allows this. >Mach-O is more universal, it allows you to assign start values to >registers (does this work in COFF as well? - I dunno.) Neither COFF nor ELF, as I remember, have this, although one way to assign start values to registers is to stick code to do so at the start address - is the ability to have "exec*()" or its moral equivalent load arbitrary values to registers useful enough that this feature is worth having? >So if COFF isn't that compatible anyway, why not start from scratch >and have a clean start? AT&T appears to agree, hence ELF....
mib@geech.gnu.ai.mit.edu (Michael I Bushnell) (05/02/91)
In article <7552@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >Mach-O is more universal, it allows you to assign start values to >registers (does this work in COFF as well? - I dunno.) Neither COFF nor ELF, as I remember, have this, although one way to assign start values to registers is to stick code to do so at the start address - is the ability to have "exec*()" or its moral equivalent load arbitrary values to registers useful enough that this feature is worth having? Yes. It allows you to have unexec programs which can't relocate the executable still function. -mib
rfg@NCD.COM (Ron Guilmette) (05/06/91)
In article <7552@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
+>and you can also store core dumps in Mach-O!
+
+COFF's replacement in S5R4, ELF, also allows this.
+
+>Mach-O is more universal, it allows you to assign start values to
+>registers (does this work in COFF as well? - I dunno.)
+
+Neither COFF nor ELF, as I remember, have this, although one way to
+assign start values to registers is to stick code to do so at the start
+address - is the ability to have "exec*()" or its moral equivalent load
+arbitrary values to registers useful enough that this feature is worth
+having?
+
+>So if COFF isn't that compatible anyway, why not start from scratch
+>and have a clean start?
+
+AT&T appears to agree, hence ELF....
As Guy points out, AT&T started fresh on object-file/core-dump formats in
System V Release 4. They also started fresh when it came to the format
used to put symbolic debugging information into their "ELF" object files.
Unlike the bad old COFF days, AT&T now uses two separate names for their
object file format and for their symbolic debugging information format.
The former is called "ELF" while the latter is called "DWARF".
Like ELF, DWARF is a significant improvement over what went before. I've
done the work to add DWARF generation to the GNU C compiler, and I'm
also now working on adding DWARF support to the GNU debugger (GDB). Thus,
I've had ample opportunities to see DWARF close up, and I'm mostly pleased
with what I've seen.
Now I know that some users of MACH will probably be using the debug info
format that OSF has done (i.e. "ROSE") but I wonder what other non-OSF
users of MACH are using (or are planning to use) when it comes to a
debugging information format? Are non-OSF MACH users using BSD stabs?
If so, why?
--
// Ron ("Loose Cannon") Guilmette
// Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg
// New motto: If it ain't broke, try using a bigger hammer.