This is the mail archive of the email@example.com mailing list for the gas2 project.
|Index Nav:||[Date Index] [Subject Index] [Author Index] [Thread Index]|
|Message Nav:||[Date Prev] [Date Next]||[Thread Prev] [Thread Next]|
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