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: About ELF and COFF


Thanks for your reply

After reading your comment, i still cann't get a concrete ideas about their
difference.
Therefore, i try to search the specification of ELF and COFF.
Once i have read these two specification, i can more understand your comment.
But, i can not find the COFF specification.
I just find the Microsoft PE and COFF file format specification.
Where i can download the UNIX COFF specification?


                                                  Thanks a lot!!

 
> > Is there any documentation about ELF is better than COFF?
> 
> Probably, though I don't know of any.
> 
> > Which problems the ELF correct that exist with COFF?
> 
> COFF has no coherent way to implement shared libraries.  COFF shared
> libraries are normally implemented by putting the shared library at a
> fixed address, and linking to that address.  This is inflexible, and
> makes it quite difficult to coordinate shared libraries from multiple
> vendors.
> 
> COFF relocations are not well specified.  All details are processor
> dependent.  (This is partially true of ELF, but at least ELF fully
> specifies the relocation format; only the details of performing the
> relocation are processor dependent.  This makes it possible to write
> generic code to examine ELF relocations.)
> 
> COFF has no way to specify required section alignment in an object
> file.
> 
> COFF has no way to specify required alignment for a common symbol.
> 
> COFF stores debugging information in the symbol table (and in a
> separate line number table), which makes it difficult to enhance as
> new debugging information tends to break existing linkers.  For
> example, debugging C++ code using COFF debugging information is hard
> and most operations do not work.  (A GNU extension is to use stabs
> debugging information instead, and store that in separate sections.
> Some people now use DWARF debugging information in COFF sections,
> which is essentially equivalent to the ELF approach.)
> 
> Many COFF implementations only permit up to 65535 relocations per
> section, which sounds like a lot but is insufficient for some real
> programs.
> 
> There is no unified way to recognize a COFF file.  Every COFF file has
> a magic number which is specific to a particular version of COFF.
> 
> Those are the deficiencies which come to mind.
> 
> Ian
> 
> 


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