Re: coff section flags: STYP_COPY, in particular, for TI COFF files

[John E Hein <jhein at timing dot com>]

Ian Lance Taylor wrote at 13:29 -0800 on Apr  5:
 > John E Hein <jhein at timing dot com> writes:
 > > 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.

In bfd, SEC_HAS_CONTENTS is set if the section size != 0 or if
SEC_LOAD is not set (which is true in the case of certain STYP_*
flags - see coffcode.h's styp_to_sec_flags()).


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

Maybe so, but I assumed that's why there's a styp_to_sec_flags
function in coffcode.h - to translate between the coff view and the bfd
view.


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

Okay... you had mentioned in your description above that it was a
link time thing, and I misunderstood what you were getting at.


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

That was my original notion of the term, but as I said, the TI
explanation of the coff section flags, says: 'The term "loaded" means
that the raw data for this section appears in the object file.'


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

Is there a knob to say allocated and zeroed?  Or is that implicit in
all allocated pieces?  You said "typically" zeroed... are there actual
known cases where it's not?  I imagine that would break some apps.
But this is a sidetrack anyway...


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

I can only go on the comments that I see in internal.h (and I've seen
elsewhere) and the comments in the TI doc (which are very similar
except perhaps for what "loaded" means).

internal.h
----------
STYP_PAD   "padding": not allocated, not relocated, loaded

STYP_COPY  "copy": for decision function used by field update;
           not allocated, not relocated, loaded;
           reloc & lineno entries processed normally

spru186l.pdf & spru102f.pdf (TI docs for c6x & c54x processors, c54x
support which is now part of binutils)
----------------
STYP_PAD   loaded, not allocated, not relocated

STYP_COPY  loaded, not allocated, relocated; relocate & line number
            entries processed normally

The only diff is relocated vs. not relocated for STYP_COPY, but I don't
care about that for what I am trying to figure out.


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

According to TI support...

"the documentation for copy section says these section will get loaded
but not allocated in the memory"

Again, remember their doc says:
'The term "loaded" means that the raw data for this section appears in
the object file.'

BTW, the BFD section flags for the STYP_COPY | STYP_DATA section are
0x243 (CONTENTS, ALLOC, LOAD, DATA).

But just plain STYP_DATA sections (like .const) also get 0x243.


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

Okay, so what are the correct docs to look at?  Any coff gurus care to
chime in (this is supposedly coff "version 2", btw)?  I've seen
snippets in various google searches that seem to have the same text as
the comments in binutils internal.h; many search hits say very little
about section types beyond text, data & bss.