This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: COFF File Format Spec


George Hicken <gh299@ecs.soton.ac.uk> writes:

> I have just discovered an urgent need for information on the COFF format
> myself, particually relocation. So if you do find any information I would
> greatly appricate it if you could forward it to me.

I don't think there were ever any specs on COFF relocation beyond what
can be found in <a.out.h> on various native SVR3 systems.  If you have
existing COFF files, you will have to determine the relocation
semantics using reverse engineering.  If you are defining new COFF
files, I recommend switching to ELF if at all possible.  If you must
stick with COFF, you will have to define your own relocation
semantics.

> What I have found so far is that COFF and Portable Executable (PE files)
> seem to be pretty much identical. I am not sure, but I believe that ECOFF
> (Microsofts flavour of COFF) is the same as PE.

Does Microsoft really have something which they call ECOFF?  There is
something else which is also called ECOFF, which is the object file
format used on SVR3 based MIPS systems.  When you see the term ECOFF
in BFD, that is what it refers to.  BFD calls the Microsoft object
file format PE and PEI (PE Image format).

In any case, COFF and PE are not the same.  PE added a bunch of
information to support DLLs, which are a poor man's version of ELF
position independent shared libraries.  Traditional COFF does not
support position independent shared libraries; SVR3 shared libraries
had a fixed address, so you needed global coordination among all
people writing shared libraries.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]