public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: John E Hein <jhein@timing.com>
To: binutils@sources.redhat.com
Subject: coff section flags: STYP_COPY, in particular, for TI COFF files
Date: Sat, 05 Apr 2003 00:48:00 -0000	[thread overview]
Message-ID: <16014.10221.454221.906570@gromit.timing.com> (raw)

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 979 bytes --]

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?



[-- Attachment #2: coffcode.h STYP_COPY, et. al., patch --]
[-- Type: text/plain, Size: 753 bytes --]

--- 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

             reply	other threads:[~2003-04-05  0:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-05  0:48 John E Hein [this message]
2003-04-05  6:48 ` Ian Lance Taylor
2003-04-05 14:44   ` Michael S. Zick
2003-04-05 20:18   ` John E Hein
2003-04-05 21:29     ` Ian Lance Taylor
2003-04-05 23:35       ` John E Hein
2003-04-07  2:55         ` Ian Lance Taylor
2003-04-07 16:54           ` John E Hein
2003-04-08 23:53             ` John E Hein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=16014.10221.454221.906570@gromit.timing.com \
    --to=jhein@timing.com \
    --cc=binutils@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).