This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: coff section flags: STYP_COPY, in particular, for TI COFF files
John E Hein <jhein at timing dot com> writes:
> Ian Lance Taylor wrote at 22:48 -0800 on Apr 4:
> > John E Hein <jhein at timing dot com> 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
In BFD terminology, that corresponds to SEC_HAS_CONTENTS.
> see comments in include/coff/internal.h, look for STYP_* and the
> comments about which sections should be relocated, allocate &/or
> loaded or not.
Those comments are very old, and may or may not correspond to the BFD
section flags.
> > 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?
``Allocated'' is not just a link time directive. The OS must also
know how to handle such a section, of course, once the linker has
decided where it is to go.
> > 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).
There is a misunderstanding here. ``Loaded'' means that the section
contents are copied from the executable file into memory at execution
time. This is not true of a .bss section--there are no section
contents to copy. ``Allocated'' means that space is set aside in the
execution time memory map; if the section is not also loaded, then
typically that space is zeroed (often implicitly via demand paging) at
execution time. Ordinary text and data sections are both ``loaded''
and ``allocated.'' BSS sections are ``allocated'' but not ``loaded.''
> FYI, the coff STYP_PAD section is "loaded, not allocated"
> (internal.h), for instance, as is STYP_COPY.
I don't know how STYP_PAD and STYP_COPY sections are to be handled, so
I don't know how they should be translated into BFD section flags.
> It's entirely possible that someone (TI?) has this all backwards?
> Or I'm just missing a piece in my mind's eye somewhere.
It does sound like the terminology is being used in some sort of
reverse sense for some reason.
> 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.
Can you describe in more detail what is supposed to happen with a
STYP_COPY section? What would be an example use of such a section?
Ignore the comments in coff/internal.h. They may be accurate, or they
may not, and in any case the version of STYP_COPY they describe may
not be the one expected by the TI tools.
Ian