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

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.