From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7236 invoked by alias); 5 May 2004 15:36:58 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 7219 invoked from network); 5 May 2004 15:36:57 -0000 Received: from unknown (HELO yosemite.airs.com) (209.128.65.135) by sources.redhat.com with SMTP; 5 May 2004 15:36:57 -0000 Received: (qmail 20602 invoked by uid 10); 5 May 2004 15:36:56 -0000 Received: (qmail 21576 invoked by uid 500); 5 May 2004 15:36:46 -0000 Mail-Followup-To: binutils@sources.redhat.com, mr924352@cs.nthu.edu.tw From: Ian Lance Taylor To: libra Cc: binutils@sources.redhat.com Subject: Re: About ELF and COFF References: <1083725373.4098563db0bdb@webmail.cs.nthu.edu.tw> Date: Wed, 05 May 2004 15:36:00 -0000 In-Reply-To: <1083725373.4098563db0bdb@webmail.cs.nthu.edu.tw> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-05/txt/msg00102.txt.bz2 libra writes: > 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