> > For READONLY, I am thinking more in line with "whether we need this
> > feature at all"... If no input has SHF_WRITE, the output naturally
> does
> > not have SHF_WRITE; if an input has SHF_WRITE, chancing the output
> to
> > non-SHF_WRITE is weird and error-prone.
> 
> I do not know if this counts as a *justified* use of READONLY, but it
> was
> used recently in an attempt to add a new feature to Fedora rawhide:
> 
>     
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects#New_system:_.note.package
> 
> The feature used a custom linker script fragment to add a note
> section
> into the executable being created, and this script used the READONLY
> keyword:
> 
>    SECTIONS
>    {
>      .note.package (READONLY) : ALIGN(4) {
>          BYTE(0x04) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of
> Owner including NUL */
>   [...]
>      }
>    }
>    INSERT AFTER .note.gnu.build-id;
> 
> This turned out to be problematic however as gold does not support
> the
> READONLY attribute, nor the INSERT AFTER directive...

Yes, we are aware of the issue with ld.gold, and are thinking about
what to do there. The main problem is that even without those
unsupported attributes, ld.gold generates broken ELFs that crash
immediately. For now, we just suggest to just use bfd whenever
possible, and skip this feature otherwise with a simple flag. It's not
great to lose debuggability and useful information, but it doesn't need
to have 100% coverage to provide utility, it's perfectly ok to miss
some packages.

> Anyway I think that the point here was that was no input section, so
> the author needed another way to tell the linker that the output
> section
> should be readonly.

Yes, this is precisely the use case, and the attribute is working as
intended - not just in Fedora, but in CBL-Mariner too, and other
internal Yocto-based use cases.

-- 
Kind regards,
Luca Boccassi