From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5428 invoked by alias); 5 Apr 2003 20:18:07 -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 5421 invoked from network); 5 Apr 2003 20:18:06 -0000 Received: from unknown (HELO Daffy.timing.com) (206.168.13.218) by sources.redhat.com with SMTP; 5 Apr 2003 20:18:06 -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 h35KI4H05841; Sat, 5 Apr 2003 13:18:04 -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 h35KI39A021947; Sat, 5 Apr 2003 13:18:03 -0700 (MST) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.12.6p2/8.12.6/Submit) id h35KI36N021944; Sat, 5 Apr 2003 13:18:03 -0700 (MST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16015.14843.148003.514706@gromit.timing.com> Date: Sat, 05 Apr 2003 20:18:00 -0000 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> X-SW-Source: 2003-04/txt/msg00152.txt.bz2 Ian Lance Taylor wrote at 22:48 -0800 on Apr 4: > John E Hein writes: > > > 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). > > How can something be loaded but not allocated? I believe... - allocated means space is reserved in the target memory at "run" time - loaded means loaded into the coff image itself, not necessarily put in the target memory see comments in include/coff/internal.h, look for STYP_* and the comments about which sections should be relocated, allocate &/or loaded or not. >From the coff description in the TI docs (http://www-s.ti.com/sc/psheets/spru186l/spru186l.pdf, p. A-7)... 'The term "loaded" means that the raw data for this section appears in the object file.' > In BFD lingo, loaded means that the section should be loaded into > memory when the program is run. Allocated means that a portion of > memory should be set aside for the section at link time. Then the STYP_* comments in binutils/include/coff/internal.h are in conflict. In the binutils include/coffcode.h, it certainly sets SEC_ALLOC and not SEC_LOAD in some cases (STYP_BSS, for instance). If 'allocated' is just a link time directive, then how does the OS know at run time what to do with it? > It's possible to have a section which is allocated but not loaded: > the .bss section is one--there is no need to load it because the > contents are known to be zero. But if a section is loaded but not > allocated, then where are you supposed to load it? This sounds opposite of what you just described. I would expect .bss to be initialized in memory with all zeroes at run time ('loaded' in your explanation of the bfd lingo). Maybe that's what you mean by allocated (except that it's also set to 0s at some point in addition to just being allocated). FYI, the coff STYP_PAD section is "loaded, not allocated" (internal.h), for instance, as is STYP_COPY. It's entirely possible that someone (TI?) has this all backwards? Or I'm just missing a piece in my mind's eye somewhere. In any case, the main bit I'm trying to work out is this... the image produced by the TI tools that has a section that should not be put into memory at run time has 0x50 section flags (STYP_DATA | STYP_COPY). According to the binutils comments in coff/internal.h, STYP_COPY means loaded, not allocated. If loaded means what you describe, as opposed to what the TI doc describes, then something is wrong. And the binutils coff code currently does nothing at all if STYP_COPY is set.