From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5308 invoked by alias); 5 Apr 2003 00:48:48 -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 5301 invoked from network); 5 Apr 2003 00:48:47 -0000 Received: from unknown (HELO Daffy.timing.com) (206.168.13.218) by sources.redhat.com with SMTP; 5 Apr 2003 00:48:47 -0000 Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.11.3/8.11.3) with ESMTP id h350mkH87753 for ; Fri, 4 Apr 2003 17:48:46 -0700 (MST) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.12.6p2/8.12.6) with ESMTP id h350mj9A015853; Fri, 4 Apr 2003 17:48:45 -0700 (MST) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.12.6p2/8.12.6/Submit) id h350mjnw015850; Fri, 4 Apr 2003 17:48:45 -0700 (MST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="4+JDRc86i9" Content-Transfer-Encoding: 7bit Message-ID: <16014.10221.454221.906570@gromit.timing.com> Date: Sat, 05 Apr 2003 00:48:00 -0000 From: John E Hein To: binutils@sources.redhat.com Subject: coff section flags: STYP_COPY, in particular, for TI COFF files X-SW-Source: 2003-04/txt/msg00132.txt.bz2 --4+JDRc86i9 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Content-length: 979 I am looking into supporting the TMS320C6x (c6x-tools.sourceforge.net), and I've found that the COFF files generated by TI's compiler (Code Composer Studio) include some sections flagged by STYP_COPY. This is not handled in bfd/coffcode.h Sections flagged by STYP_COPY are to be relocated and loaded, but not allocated. For instance, there's a .vers section that has section flags 0x50 (STYP_COPY | STYP_DATA). binutils marks these with SEC_LOAD & SEC_ALLOC (loaded & allocated). In recent TI tools (CCS 2.20), there's another section ($BRID) which has the same problem. Note that the c54x support that is now included in binutils has the same flaw. There are also problems with STYP_DSECT (not handled by binutils in sec_to_styp_flags()) and also with STYP_PAD (should be loaded, but not marked by binutils with SEC_LOAD). But I haven't seen a COFF file generated by the TI tools that have the STYP_DSECT nor STYP_PAD flags set (yet). Attached is a patch. Comments? --4+JDRc86i9 Content-Type: text/plain Content-Description: coffcode.h STYP_COPY, et. al., patch Content-Disposition: inline; filename="patch" Content-Transfer-Encoding: 7bit Content-length: 753 --- coffcode.h.orig Fri Apr 4 17:41:35 2003 +++ coffcode.h Fri Apr 4 17:43:41 2003 @@ -644,8 +644,10 @@ sec_flags |= SEC_DEBUGGING; #endif } + else if ((styp_flags & STYP_PAD) && (sec_flags & SEC_NEVER_LOAD)) + sec_flags = 0; else if (styp_flags & STYP_PAD) - sec_flags = 0; + sec_flags = SEC_LOAD; else if (strcmp (name, _TEXT) == 0) { if (sec_flags & SEC_NEVER_LOAD) @@ -702,6 +704,9 @@ if (styp_flags & STYP_OTHER_LOAD) sec_flags = (SEC_LOAD | SEC_ALLOC); #endif /* STYP_SDATA */ + + if (styp_flags & (STYP_COPY | STYP_DSECT)) + sec_flags &= ~SEC_ALLOC); #if defined (COFF_LONG_SECTION_NAMES) && defined (COFF_SUPPORT_GNU_LINKONCE) /* As a GNU extension, if the name begins with .gnu.linkonce, we --4+JDRc86i9--