Re: rationale for bss patterns in default_section_type_flags ?

[Brett Porter <porter at adacore dot com>]

> Ultimately, people just pick names.  Once picked, they form crystal
> clear standards.

So there is no documented standard involved.

> >> No, the standard is to be prefix based, this simplifies the impact on
> >> the linker scripts.
> >
> > Ok. So a new category of bss sections could be matched by
> > "X.bss" or "X.bss."*.  Would that be reasonable?
>
> _prefix_, not suffix.  No.  You'd first have to explain why the
> existing standard of prefix can't be made to work I think.  .bss.X
> would be the convention to use.

"X.bss" would be the prefix (like .sbss and .gnu.linkonce.b. in
default_section_type_flags_1) and the desire is have a .bss-like section
with a difference, that is not included in any .bss.* wildcard patterns
in a linker script.  The situation is: in an embedded system, certain
variables are placed in .persistent.bss (name is not our choice :( );
upon an initial load the section is zeroed just like .bss; there are
conditions where the program is restarted but the loader will not
zero this section (in battery-backed RAM) during the restart. The
easiest implementation would be to add

  || strcmp (name, ".persistent.bss") == 0

to the list in default_section_type_flags_1 and it doesn't
seem likely that .persistent.bss should not have SECTION_BSS
set?)  Of course, it would only be used in a system where
the linker and loader are prepared for it.

Brett