Re: [RFA] Coff SEC_LOAD vs SEC_NEVER_LOAD

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

"Svein E. Seldal" <Svein.Seldal@solidas.com> writes:

> What is the relation between SEC_LOAD and the SEC_NEVER_LOAD section flags?
> 
> When I tag a coff section with the STYP_NOLOAD flag, objdump reports
> that the section's flags are ALLOC, LOAD, NEVER_LOAD. This seems to
> create trouble as GDB seems to load every section that are tagged with
> LOAD, regardless of NEVER_LOAD's value. Now, this could well be a bug
> in GDB, but I dont understand why we need SEC_LOAD and
> SEC_NEVER_LOAD. They are complementary, aren't they?

Well, no, not really.  SEC_NEVER_LOAD isn't very well defined.  I
think it was intended to override the SEC_LOAD flag, to essentially
say that, despite appearances, the section really shouldn't be loaded.
It gets turned on for COFF STYP_NOLOAD sections, and for output
sections marked as NOLOAD in linker scripts.

The ChangeLog indicates that SAC introduced it for COFF STYP_INFO
sections, and I picked it up for COFF STYP_NOLOAD sections and then,
in fact, dropped it for STYP_INFO.

(When the linker sees a NOLOAD section, it doesn't generate the
bfd_indirect_link_order struct which would normally map an input
section to an output section.  However, most of the new linker
backends, for efficiency, more or less ignore the
bfd_indirect_link_order structs anyhow, and instead link based on
input files rather than input sections.)

To put it another way, most of the section flags are used to represent
characteristics of sections in input files.  However, SEC_NEVER_LOAD
is also to indicate an action in the linker.  That is why you can see
SEC_LOAD and SEC_NEVER_LOAD both set.  In principle the BFD backend
should handle this case by marking the section as not loadable.  But
most of the backends ignore SEC_NEVER_LOAD.

This semantic confusion seems unwise to me.  Probably the best
approach would be, as you imply, to remove all instances of
SEC_NEVER_LOAD and replace them with !SEC_LOAD plus some additional
flags in the internal linker structures.

And let's not even get into SEC_SHARED_LIBRARY, now renamed to
SEC_COFF_SHARED_LIBRARY.  I don't know what I was thinking back then.

Ian