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

[Ian Lance Taylor <ian at airs dot com>]

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