This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: About ELF and COFF
- From: libra <mr924352 at cs dot nthu dot edu dot tw>
- To: binutils at sources dot redhat dot com
- Date: Mon, 10 May 2004 17:22:13 +0800
- Subject: 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
>
>