From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8097 invoked by alias); 7 Apr 2003 16:54:43 -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 8090 invoked from network); 7 Apr 2003 16:54:41 -0000 Received: from unknown (HELO Daffy.timing.com) (206.168.13.218) by sources.redhat.com with SMTP; 7 Apr 2003 16:54:41 -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 h37GseH29365 for ; Mon, 7 Apr 2003 10:54:40 -0600 (MDT) (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 h37Gsd9A033766; Mon, 7 Apr 2003 10:54:39 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.12.6p2/8.12.6/Submit) id h37Gsd4K033763; Mon, 7 Apr 2003 10:54:39 -0600 (MDT) Date: Mon, 07 Apr 2003 16:54:00 -0000 Message-Id: <200304071654.h37Gsd4K033763@gromit.timing.com> Resent-Message-ID: <16017.44367.152672.733174@gromit.timing.com> Resent-Date: Mon, 7 Apr 2003 10:54:39 -0600 Resent-From: John E Hein MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: John E Hein To: Ian Lance Taylor CC: binutils@sources.redhat.com Subject: Re: coff section flags: STYP_COPY, in particular, for TI COFF files In-Reply-To: References: <16014.10221.454221.906570@gromit.timing.com> <16015.14843.148003.514706@gromit.timing.com> <16015.26689.655347.895243@gromit.timing.com> X-SW-Source: 2003-04/txt/msg00172.txt.bz2 Ian Lance Taylor wrote at 19:55 -0700 on Apr 6: > Well, given their definition of ``loaded,'' it sounds to me like an > STYP_COPY section is one which has contents, but the contents are not > copied into memory at execution time. This is true, for example, of a > section which holds debugging information. In BFD terms, I think such > a section would be SEC_HAS_CONTENTS, but no other flags (except maybe > SEC_RELOC). Right, that's what I was trying to do with the original patch to coffcode.h (where I tried to handle the previously unhandled STYP_COPY in a way consistent with the comments in internal.h). Unfortunately, the general COFF code may not be the place if TI's COFF treatment is sufficiently abnormal. But I did try to match the comments in internal.h - if those are wrong, I suppose they should be fixed - or words added to indicate that different COFF implementation may differ with their intended use of STYP_* flags. Instead of modifying the general COFF handling in binutils, I may rather want to override that behavior for TI COFF. > The only way to know whether this makes any sense is to examine the > actual behaviour of the TI tools when given a STYP_COPY section. For > example: how is an STYP_COPY section created in the first place? What > happens to an STYP_COPY section at link time? At run time? I have asked TI support for a more detailed explanation regarding how their tools behave for various section types. We'll see what they have to say. > One of the reasons why people should avoid COFF is that it was never > properly documented. The AT&T docs said nothing useful. There was an > O'Reilly book a while back, now out of print, which is more or less > ``everything you wanted to know about COFF except what you really need > to know.'' So, I'm finding out. > I checked the O'Reilly book, and it does not mention STYP_COPY. My > SVR3 docs are sufficiently buried that I don't really feel like > searching for them. I would be surprised if they mention STYP_COPY. Someone else here had the O'Reilly COFF book, too (1988). As you say, it wasn't much help. Does anyone know who was the original porter(s) of C54x to binutils? Maybe they can point to something that clears it up.