Re: traditional Intel & Microsoft formats...

[John Gilmore <gnu@cygnus.com>]

I applaud your effort to support more file formats in the hope of
making it possible to run (proprietary or free) programs from the
PC world on GNU systems.  Have you examined the Wine emulator
for Windows programs?  And the "sim" directory of instruction-set
simulators in the GDB releases?  Some of us have similar dreams...

Specs for some of the formats you are interested in *are* available
and don't have to be reverse-engineered.  (Some other info, such as
debug sections, may require more work -- I haven't checked into all the
details.)  There's an organization of OS and tool companies called the
Tool Interface Standards committee.  It publishes specs and talks
about new formats and revisions.  Cygnus asked how we could join one
time, but never got a response.  Here are my old notes about this:

Subject: [Intel x86] Tool Interface Standards committee

Announced in Open Systems Today, March 1, 1993.  Committee is Borland,
IBM, Intel, Lotus, MetaWare, Microsoft, SCO, Watcom.

Contact: David Bernstein, director of technology at SCO.

Volume 1:  Portable executable format (from Windows NT) and STI (symbol
	   and type information).
Volume 2:  ELF, DWARF, and OMF.

Version 1.0 of the standard is free of charge (in hard copy) on request.
Available from Intel.  +1 800 548 4725
Order # 241-597
Takes 7-10 working days.

Arrived from:

	Tool Interface Standards 
	c/o Intel Corporation
	RN6-30
	2200 Mission College Blvd.
	Santa Clara, CA  95052

signature space left for "Secretary, TIS Committee", but not signed.

"The TIS Committee is an open forum in which corporations can provide
leadership for advancing the PC software market.  The Committee
welcomes participation by new company members.  Interested companies
can learn more about TIS by using Intel ACCESS on CompuServe."

	John

The Tool Interface Standards ad-hoc committee has produced two
documents, describing ELF, DWARF (almost 2.0), OMF, PE, and STI object
formats.

The intent is that every vendor's tools can interoperate, at least on
Intel x86 platforms.  Some of the formats describe other CPUs as well.

The committee is currently Borland, IBM, Intel, Lotus, Metaware,
Microsoft, SCO, and Watcom, with help from PharLap and Symantec.

The standards haven't been jiggered -- e.g. ELF is the real thing.
ELF is the only one that we currently support.  Our DWARF support is
for a previous rev, and we don't do OMF (which is used for DOS and
OS/2 relocatable files), PE (Windows NT executable, basically COFF),
and STI (Windows NT debug info).  But now we can if we want to.

    ---

By the way, it looks to me like Windows DLL linking is remarkably like
dynamic linking on SVR4 or SunOS.  Since the GNU Linker now supports
dynamic linking (which was, indeed, a fair bit of work), making it
handle DLL's is probably not as big a job as you think.

The way to support any of these formats is to write a new BFD
back-end.  It's really pretty easy.  Look at one of the simple ones
that isn't full of macros -- say, binary.c or tekhex.c or srec.c or
oasys.c.  (The macro-ized bfd target code is to support seventeen
variants of a.out or COFF on seventeen Unix machines.)  To read a new
file format, you only need to write a dozen functions (check file
format, get section info, get section contents, get symbol table size,
get symbol table, etc).  Once you get this simple stuff into a BFD
target, you get immense leverage from the already-99%-working code
in the assembler, linker, binutils, and GDB that calls BFD.

	John Gilmore
	Cygnus Support