Output section type (READONLY)

Output section type (READONLY)

[Fangrui Song]

[PATCH v2] ld: add READONLY attribute for SECTIONS
(https://sourceware.org/pipermail/binutils/2021-July/117492.html) added
READONLY. There was no justification as to why it was added.

It was presumably to make an output section non-writable by default.
But for

   % cat output-section-types.t
   SECTIONS {
     .rom  (NOLOAD)   : { LONG(1234); }
     .ro (READONLY)   : { LONG(5678); }
     .over (OVERLAY)  : { LONG(0123); }
     /DISCARD/        : { *(*) }
   }

.ro does not have the SHF_WRITE flag even without (READONLY).
The unneeded SHF_WRITE flag has been fixed by Alan for
https://sourceware.org/bugzilla/show_bug.cgi?id=26378#c11 .

---

Well, READONLY has another behavior that it forces non-SHF_WRITE output
even if an input section has the SHF_WRITE flag.

   % cat output-section-types.t
   SECTIONS {
     .rom  (NOLOAD)   : { LONG(1234); }
     .ro (READONLY)   : { LONG(5678); *(.ro) }
     .over (OVERLAY)  : { LONG(0123); }
     /DISCARD/        : { *(*) }
   }
   % cat x.s
   .section .ro,"aw"
   .quad 0

The output .ro does not have SHF_WRITE. There is no warning.

  [ 2] .ro               PROGBITS        0000000000000004 001004 000004 00   A  0   0  1

I find this quite dangerous if an input section has the SHF_WRITE flag.
I do not see in what circumstances a user may want this behavior.
This just seems very dangerous to use in general.
What went lucky is that
https://sourceware.org/binutils/docs/ld/Output-Section-Type.html does not have
the feature listed yet, so hopefully very few people will be lured to use this.

Re: Re: Output section type (READONLY)

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

> [PATCH v2] ld: add READONLY attribute for SECTIONS
> (https://sourceware.org/pipermail/binutils/2021-July/117492.html)
> added
> READONLY. There was no justification as to why it was added.

It was already explained - READONLY is necessary for notes, otherwise
they are marked as writable:

[ 3] .note.package     NOTE             00000000000002e8  000002e8
  0000000000000030  0000000000000000  WA       0     0     4

> What went lucky is that
> https://sourceware.org/binutils/docs/ld/Output-Section-Type.html does
> not have
> the feature listed yet, so hopefully very few people will be lured to
> use this.

The documentation update is already committed in the repository, I
imagine it will be published on the website after the new release is
out.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Re: Output section type (READONLY)

[Fangrui Song]

On Sat, Jan 29, 2022 at 8:46 AM Luca Boccassi <luca.boccassi@gmail.com> wrote:
>
> > [PATCH v2] ld: add READONLY attribute for SECTIONS
> > (https://sourceware.org/pipermail/binutils/2021-July/117492.html)
> > added
> > READONLY. There was no justification as to why it was added.
>
> It was already explained - READONLY is necessary for notes, otherwise
> they are marked as writable:
>
> [ 3] .note.package     NOTE             00000000000002e8  000002e8
>   0000000000000030  0000000000000000  WA       0     0     4

In GNU ld, SHT_NOTE special sections don't have the SHF_WRITE flag.
I don't see how READONLY is necessary.

If in some case a SHT_NOTE section has  the SHF_WRITE flag,
it more likely suggests an unknown bug which should not be papered over by
adding READONLY.

> > What went lucky is that
> > https://sourceware.org/binutils/docs/ld/Output-Section-Type.html does
> > not have
> > the feature listed yet, so hopefully very few people will be lured to
> > use this.
>
> The documentation update is already committed in the repository, I
> imagine it will be published on the website after the new release is
> out.
>
> --
> Kind regards,
> Luca Boccassi

Re: Output section type (READONLY)

[Nick Clifton]

Hi Fangrui,

> Well, READONLY has another behavior that it forces non-SHF_WRITE output
> even if an input section has the SHF_WRITE flag.

> I find this quite dangerous if an input section has the SHF_WRITE flag.
> I do not see in what circumstances a user may want this behavior.
> This just seems very dangerous to use in general.

So basically what you are saying is that if a input section is assigned
to an output sections with incompatible attributes (presumably because of a
linker script declaration) then the linker should issue a warning message,
yes ?

By extension then, this feature should cover not just the readonly section
attribute, but the NOLOAD attribute as well.

This sounds like it might be an interesting feature to implement for someone
looking to gain experience with the binutils.

Cheers
   Nick

Re: Output section type (READONLY)

[Fangrui Song]

On 2022-01-31, Nick Clifton wrote:
>Hi Fangrui,
>
>>Well, READONLY has another behavior that it forces non-SHF_WRITE output
>>even if an input section has the SHF_WRITE flag.
>
>>I find this quite dangerous if an input section has the SHF_WRITE flag.
>>I do not see in what circumstances a user may want this behavior.
>>This just seems very dangerous to use in general.
>
>So basically what you are saying is that if a input section is assigned
>to an output sections with incompatible attributes (presumably because of a
>linker script declaration) then the linker should issue a warning message,
>yes ?
>
>By extension then, this feature should cover not just the readonly section
>attribute, but the NOLOAD attribute as well.

For NOLOAD, .noload (NOLOAD) : { *(.noload) } makes the output .noload
SHT_NOBITS even if there is a non-empty SHT_PROGBITS .noload section.
I don't know whether the linker should issue a warning.

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.

>This sounds like it might be an interesting feature to implement for someone
>looking to gain experience with the binutils.

Ah, sure:)

>Cheers
>  Nick
>
>
>
>

Re: Output section type (READONLY)

[Nick Clifton]

Hi Fangrui,

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

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.

Cheers
   Nick

Re: Re: Output section type (READONLY)

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Output section type (READONLY)

[Fangrui Song]

Hi Luca and Nick,

On 2022-02-01, Luca Boccassi wrote:
>> > 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;

Yes, I recently learned that Fedora started to use (READONLY).
The usage feels strange to me as .note.package should not have the
SHF_WRITE flag, even without READONLY....

In https://sourceware.org/bugzilla/show_bug.cgi?id=26378#c11 , Alan
changed such sections to be read-only by default in 2020 to support a
Linux use case. I do not understand why a new keyword has to be
invented...

The next thing I feel uncomfortable with is the abuse of .note* indicates
a SHT_NOTE section. The type, in my opinion, should be explicitly
specified. In ELF, attributes are identified as well known integers.
The magic section prefix ".note" is contrary to this.

I shall add a note that gold doesn't magically set an output section .note*
to SHT_NOTE and this behavior makes a lot of sense to me.

To allow forward progress, I created
https://sourceware.org/pipermail/binutils/2022-February/119591.html
(ld: Support customized output section type) and I'd recommend that the
linker script fragment

   .note.package (READONLY) : ALIGN(4) {

switches to

   .note.package (TYPE=SHT_NOTE) : ALIGN(4) {

>> This turned out to be problematic however as gold does not support
>> the
>> READONLY attribute, nor the INSERT AFTER directive...

This is the reason that I really recommend a synthesized .o file,
instead of a synthesized output section description using data
commands...


>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

Re: Output section type (READONLY)

[Michael Matz]

Hello,

On Tue, 1 Feb 2022, Fangrui Song wrote:

> On 2022-02-01, Luca Boccassi wrote:
> >> > 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;
> 
> Yes, I recently learned that Fedora started to use (READONLY).
> The usage feels strange to me as .note.package should not have the
> SHF_WRITE flag, even without READONLY....
> 
> In https://sourceware.org/bugzilla/show_bug.cgi?id=26378#c11 , Alan
> changed such sections to be read-only by default in 2020 to support a
> Linux use case. I do not understand why a new keyword has to be
> invented...

Agreed.

> The next thing I feel uncomfortable with is the abuse of .note* indicates
> a SHT_NOTE section. The type, in my opinion, should be explicitly
> specified. In ELF, attributes are identified as well known integers.
> The magic section prefix ".note" is contrary to this.
> 
> I shall add a note that gold doesn't magically set an output section .note*
> to SHT_NOTE and this behavior makes a lot of sense to me.
> 
> To allow forward progress, I created
> https://sourceware.org/pipermail/binutils/2022-February/119591.html
> (ld: Support customized output section type) and I'd recommend that the
> linker script fragment
> 
>    .note.package (READONLY) : ALIGN(4) {
> 
> switches to
> 
>    .note.package (TYPE=SHT_NOTE) : ALIGN(4) {

Also agreed.

(We can't remove the implicit .note* -> SHT_NOTE behaviour anymore, but it 
shouldn't have been there from the beginning).

> >> This turned out to be problematic however as gold does not support
> >> the
> >> READONLY attribute, nor the INSERT AFTER directive...
> 
> This is the reason that I really recommend a synthesized .o file,
> instead of a synthesized output section description using data
> commands...

More agreement.  I also think that the synthesized sections should rather 
be thought of as and handled like (by ld) input sections, going through 
the normal linker processing (which would remove the need for "INSERT 
AFTER").  That's a largish change, so not something we can do now anymore, 
probably.

IOW: I think the introduction of READONLY was ill-advised :-/  But, ... 
well :)


Ciao,
Michael.

Re: Output section type (READONLY)

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 4137 bytes --]

On Wed, 2022-02-02 at 16:54 +0000, Michael Matz wrote:
> Hello,
> 
> On Tue, 1 Feb 2022, Fangrui Song wrote:
> 
> > On 2022-02-01, Luca Boccassi wrote:
> > > > > 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;
> > 
> > Yes, I recently learned that Fedora started to use (READONLY).
> > The usage feels strange to me as .note.package should not have the
> > SHF_WRITE flag, even without READONLY....
> > 
> > In https://sourceware.org/bugzilla/show_bug.cgi?id=26378#c11 , Alan
> > changed such sections to be read-only by default in 2020 to support a
> > Linux use case. I do not understand why a new keyword has to be
> > invented...
> 
> Agreed.
> 
> > The next thing I feel uncomfortable with is the abuse of .note* indicates
> > a SHT_NOTE section. The type, in my opinion, should be explicitly
> > specified. In ELF, attributes are identified as well known integers.
> > The magic section prefix ".note" is contrary to this.
> > 
> > I shall add a note that gold doesn't magically set an output section .note*
> > to SHT_NOTE and this behavior makes a lot of sense to me.
> > 
> > To allow forward progress, I created
> > https://sourceware.org/pipermail/binutils/2022-February/119591.html
> > (ld: Support customized output section type) and I'd recommend that the
> > linker script fragment
> > 
> >    .note.package (READONLY) : ALIGN(4) {
> > 
> > switches to
> > 
> >    .note.package (TYPE=SHT_NOTE) : ALIGN(4) {
> 
> Also agreed.
> 
> (We can't remove the implicit .note* -> SHT_NOTE behaviour anymore, but it 
> shouldn't have been there from the beginning).
> 
> > > > This turned out to be problematic however as gold does not support
> > > > the
> > > > READONLY attribute, nor the INSERT AFTER directive...
> > 
> > This is the reason that I really recommend a synthesized .o file,
> > instead of a synthesized output section description using data
> > commands...
> 
> More agreement.  I also think that the synthesized sections should rather 
> be thought of as and handled like (by ld) input sections, going through 
> the normal linker processing (which would remove the need for "INSERT 
> AFTER").  That's a largish change, so not something we can do now anymore, 
> probably.

Compiled object do not work and cannot possibly work sanely in this
context. It is hard enough to make a simple and trivial linker script
work reliably across ~30.000 packages with god-knows-how-many different
build systems on a dozen different architectures, so it's just not
going to happen, sorry. Linker scripts exist and, to the best of my
knowledge, are still supported and supposed to work, so we are using
them.

> IOW: I think the introduction of READONLY was ill-advised :-/  But, ... 
> well :)

If you have an alternative solution to make a linker script create a
read-only note section to be inserted after another section we'd love
to hear it. So far we haven't found any, but it's possible we missed
something, of course.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Output section type (READONLY)

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

  Hi Guys,

   I have gone ahead and applied an update form of Fanguri's patch (attached).

   I extended the patch so that READONLY and type=<typename> can be used together
   if desired, like this:

     .ro.note   (READONLY (TYPE=SHT_NOTE)) : { LONG(5678); }

   (I chose this particular syntax because it was the easiest to implement.

   Other than that the patch retains all of the features in the original submission:

https://sourceware.org/pipermail/binutils/2022-February/119600.html

Cheers
   Nick

[-- Attachment #2: binutils-section-type.patch --]
[-- Type: text/x-patch, Size: 13287 bytes --]

diff --git a/bfd/bfd-in2.h b/bfd/bfd-in2.h
index 3b2a4f49a9b..78a0a1dea42 100644
--- a/bfd/bfd-in2.h
+++ b/bfd/bfd-in2.h
@@ -1170,6 +1170,9 @@ typedef struct bfd_section
     This is used when support for non-contiguous memory regions is enabled.  */
  struct bfd_section *already_assigned;
 
+  /* Explicitly specified section type, if non-zero. */
+  unsigned int type;
+
 } asection;
 
 /* Relax table contains information about instructions which can
@@ -1352,8 +1355,8 @@ discarded_section (const asection *sec)
   /* symbol,                    symbol_ptr_ptr,                     */ \
      (struct bfd_symbol *) SYM, &SEC.symbol,                           \
                                                                        \
-  /* map_head, map_tail, already_assigned                           */ \
-     { NULL }, { NULL }, NULL                                          \
+  /* map_head, map_tail, already_assigned, type                     */ \
+     { NULL }, { NULL }, NULL, 0                                       \
                                                                        \
     }
 
diff --git a/bfd/elf.c b/bfd/elf.c
index a67415e76e1..82b53be99f9 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -3280,7 +3280,9 @@ elf_fake_sections (bfd *abfd, asection *asect, void *fsarg)
 
   /* If the section type is unspecified, we set it based on
      asect->flags.  */
-  if ((asect->flags & SEC_GROUP) != 0)
+  if (asect->type != 0)
+    sh_type = asect->type;
+  else if ((asect->flags & SEC_GROUP) != 0)
     sh_type = SHT_GROUP;
   else
     sh_type = bfd_elf_get_default_section_type (asect->flags);
diff --git a/bfd/section.c b/bfd/section.c
index 899438a1c5e..2de7dbf661a 100644
--- a/bfd/section.c
+++ b/bfd/section.c
@@ -737,8 +737,8 @@ CODE_FRAGMENT
 .  {* symbol,                    symbol_ptr_ptr,                     *}	\
 .     (struct bfd_symbol *) SYM, &SEC.symbol,				\
 .									\
-.  {* map_head, map_tail, already_assigned                           *}	\
-.     { NULL }, { NULL }, NULL						\
+.  {* map_head, map_tail, already_assigned, type                     *}	\
+.     { NULL }, { NULL }, NULL, 0						\
 .									\
 .    }
 .
diff --git a/ld/NEWS b/ld/NEWS
index dbb402d1f8a..a498abaf0f9 100644
--- a/ld/NEWS
+++ b/ld/NEWS
@@ -1,5 +1,8 @@
 -*- text -*-
 
+* TYPE=<type> is now supported in an output section description to set the
+  section type value.
+
 Changes in 2.38:
 
 * Add -z pack-relative-relocs/-z no pack-relative-relocs to x86 ELF
diff --git a/ld/ld.texi b/ld/ld.texi
index fc75e9b3625..d57e9221410 100644
--- a/ld/ld.texi
+++ b/ld/ld.texi
@@ -5483,13 +5483,23 @@ loaded into memory when the program is run.
 @item READONLY
 The section should be marked as read-only.
 @item DSECT
-@itemx COPY
-@itemx INFO
-@itemx OVERLAY
+@item COPY
+@item INFO
+@item OVERLAY
 These type names are supported for backward compatibility, and are
 rarely used.  They all have the same effect: the section should be
 marked as not allocatable, so that no memory is allocated for the
 section when the program is run.
+@item TYPE = @var{type}
+Set the section type to the integer @var{type}. When generating an ELF
+output file, type names @code{SHT_PROGBITS}, @code{SHT_STRTAB},
+@code{SHT_NOTE}, @code {SHT_NOBITS}, @code{SHT_INIT_ARRAY},
+@code{SHT_FINI_ARRAY}, and @code{SHT_PREINIT_ARRAY} are also allowed
+for @var{type}.  It is the user's responsibility to ensure that any
+special requirements of the section type are met.
+@item READONLY ( TYPE = @var{type} )
+This form of the syntax combines the @var{READONLY} type with the
+type specified by @var{type}.
 @end table
 
 @kindex NOLOAD
diff --git a/ld/ldgram.y b/ld/ldgram.y
index 11c2f219c05..3a904e39482 100644
--- a/ld/ldgram.y
+++ b/ld/ldgram.y
@@ -47,6 +47,7 @@
 #endif
 
 static enum section_type sectype;
+static etree_type *sectype_value;
 static lang_memory_region_type *region;
 
 static bool ldgram_had_keep = false;
@@ -139,6 +140,7 @@ static int error_index;
 %token LD_FEATURE
 %token NOLOAD DSECT COPY INFO OVERLAY
 %token READONLY
+%token TYPE
 %token DEFINED TARGET_K SEARCH_DIR MAP ENTRY
 %token <integer> NEXT
 %token SIZEOF ALIGNOF ADDR LOADADDR MAX_K MIN_K
@@ -1058,9 +1060,8 @@ section:	NAME
 			{
 			  ldlex_popstate ();
 			  ldlex_wild ();
-			  lang_enter_output_section_statement($1, $3, sectype,
-							      $5, $7, $4,
-							      $8, $6);
+			  lang_enter_output_section_statement ($1, $3, sectype,
+					sectype_value, $5, $7, $4, $8, $6);
 			}
 		'{'
 		statement_list_opt
@@ -1130,8 +1131,10 @@ type:
 	|  COPY    { sectype = noalloc_section; }
 	|  INFO    { sectype = noalloc_section; }
 	|  OVERLAY { sectype = noalloc_section; }
+        |  READONLY '(' TYPE '=' exp ')' { sectype = typed_readonly_section; sectype_value = $5; }
 	|  READONLY { sectype = readonly_section; }
-	;
+	|  TYPE '=' exp { sectype = type_section; sectype_value = $3; }
+        ;
 
 atype:
 		'(' type ')'
diff --git a/ld/ldlang.c b/ld/ldlang.c
index 474784c874a..1733f8e65c4 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -1891,8 +1891,8 @@ lang_insert_orphan (asection *s,
     address = exp_intop (0);
 
   os_tail = (lang_output_section_statement_type **) lang_os_list.tail;
-  os = lang_enter_output_section_statement (secname, address, normal_section,
-					    NULL, NULL, NULL, constraint, 0);
+  os = lang_enter_output_section_statement (
+      secname, address, normal_section, 0, NULL, NULL, NULL, constraint, 0);
 
   if (add_child == NULL)
     add_child = &os->children;
@@ -2635,10 +2635,12 @@ lang_add_section (lang_statement_list_type *ptr,
     case normal_section:
     case overlay_section:
     case first_overlay_section:
+    case type_section:
       break;
     case noalloc_section:
       flags &= ~SEC_ALLOC;
       break;
+    case typed_readonly_section:
     case readonly_section:
       flags |= SEC_READONLY;
       break;
@@ -4209,6 +4211,7 @@ map_input_to_output_sections
     {
       lang_output_section_statement_type *tos;
       flagword flags;
+      unsigned int type = 0;
 
       switch (s->header.type)
 	{
@@ -4264,6 +4267,42 @@ map_input_to_output_sections
 	    case readonly_section:
 	      flags |= SEC_READONLY;
 	      break;
+	    case typed_readonly_section:
+	      flags |= SEC_READONLY;
+	      /* Fall through.  */
+	    case type_section:
+	      if (os->sectype_value->type.node_class == etree_name
+		  && os->sectype_value->type.node_code == NAME)
+		{
+		  const char *name = os->sectype_value->name.name;
+		  if (strcmp (name, "SHT_PROGBITS") == 0)
+		    type = SHT_PROGBITS;
+		  else if (strcmp (name, "SHT_STRTAB") == 0)
+		    type = SHT_STRTAB;
+		  else if (strcmp (name, "SHT_NOTE") == 0)
+		    type = SHT_NOTE;
+		  else if (strcmp (name, "SHT_NOBITS") == 0)
+		    type = SHT_NOBITS;
+		  else if (strcmp (name, "SHT_INIT_ARRAY") == 0)
+		    type = SHT_INIT_ARRAY;
+		  else if (strcmp (name, "SHT_FINI_ARRAY") == 0)
+		    type = SHT_FINI_ARRAY;
+		  else if (strcmp (name, "SHT_PREINIT_ARRAY") == 0)
+		    type = SHT_PREINIT_ARRAY;
+		  else
+		    einfo (_ ("%F%P: invalid type for output section `%s'\n"),
+			   os->name);
+		}
+	     else
+	       {
+		 exp_fold_tree_no_dot (os->sectype_value);
+		 if (expld.result.valid_p)
+		   type = expld.result.value;
+		 else
+		   einfo (_ ("%F%P: invalid type for output section `%s'\n"),
+			  os->name);
+	       }
+	      break;
 	    case noload_section:
 	      if (bfd_get_flavour (link_info.output_bfd)
 		  == bfd_target_elf_flavour)
@@ -4276,6 +4315,7 @@ map_input_to_output_sections
 	    init_os (os, flags | SEC_READONLY);
 	  else
 	    os->bfd_section->flags |= flags;
+	  os->bfd_section->type = type;
 	  break;
 	case lang_input_section_enum:
 	  break;
@@ -7506,6 +7546,7 @@ lang_output_section_statement_type *
 lang_enter_output_section_statement (const char *output_section_statement_name,
 				     etree_type *address_exp,
 				     enum section_type sectype,
+				     etree_type *sectype_value,
 				     etree_type *align,
 				     etree_type *subalign,
 				     etree_type *ebase,
@@ -7523,10 +7564,12 @@ lang_enter_output_section_statement (const char *output_section_statement_name,
       os->addr_tree = address_exp;
     }
   os->sectype = sectype;
-  if (sectype != noload_section)
-    os->flags = SEC_NO_FLAGS;
-  else
+  if (sectype == type_section || sectype == typed_readonly_section)
+    os->sectype_value = sectype_value;
+  else if (sectype == noload_section)
     os->flags = SEC_NEVER_LOAD;
+  else
+    os->flags = SEC_NO_FLAGS;
   os->block_value = 1;
 
   /* Make next things chain into subchain of this.  */
@@ -8842,7 +8885,7 @@ lang_enter_overlay_section (const char *name)
   etree_type *size;
 
   lang_enter_output_section_statement (name, overlay_vma, overlay_section,
-				       0, overlay_subalign, 0, 0, 0);
+				       0, 0, overlay_subalign, 0, 0, 0);
 
   /* If this is the first section, then base the VMA of future
      sections on this one.  This will work correctly even if `.' is
diff --git a/ld/ldlang.h b/ld/ldlang.h
index 0d057c9bee9..95f6e468b30 100644
--- a/ld/ldlang.h
+++ b/ld/ldlang.h
@@ -122,7 +122,9 @@ enum section_type
   overlay_section,
   noload_section,
   noalloc_section,
-  readonly_section
+  type_section,
+  readonly_section,
+  typed_readonly_section
 };
 
 /* This structure holds a list of program headers describing
@@ -166,6 +168,7 @@ typedef struct lang_output_section_statement_struct
   int constraint;
   flagword flags;
   enum section_type sectype;
+  etree_type *sectype_value;
   unsigned int processed_vma : 1;
   unsigned int processed_lma : 1;
   unsigned int all_input_readonly : 1;
@@ -545,7 +548,7 @@ extern void lang_add_output
   (const char *, int from_script);
 extern lang_output_section_statement_type *lang_enter_output_section_statement
   (const char *, etree_type *, enum section_type, etree_type *, etree_type *,
-   etree_type *, int, int);
+   etree_type *, etree_type *, int, int);
 extern void lang_final
   (void);
 extern void lang_relax_sections
diff --git a/ld/ldlex.l b/ld/ldlex.l
index 78db16e3a48..c38b46b9336 100644
--- a/ld/ldlex.l
+++ b/ld/ldlex.l
@@ -323,6 +323,7 @@ V_IDENTIFIER [*?.$_a-zA-Z\[\]\-\!\^\\]([*?.$_a-zA-Z0-9\[\]\-\!\^\\]|::)*
 <EXPRESSION>"DSECT"			{ RTOKEN(DSECT); }
 <EXPRESSION>"COPY"			{ RTOKEN(COPY); }
 <EXPRESSION>"INFO"			{ RTOKEN(INFO); }
+<EXPRESSION>"TYPE"			{ RTOKEN(TYPE); }
 <SCRIPT,EXPRESSION>"ONLY_IF_RO"		{ RTOKEN(ONLY_IF_RO); }
 <SCRIPT,EXPRESSION>"ONLY_IF_RW"		{ RTOKEN(ONLY_IF_RW); }
 <SCRIPT,EXPRESSION>"SPECIAL"		{ RTOKEN(SPECIAL); }
diff --git a/ld/mri.c b/ld/mri.c
index b428ab0d0bf..5749870ef1e 100644
--- a/ld/mri.c
+++ b/ld/mri.c
@@ -210,8 +210,8 @@ mri_draw_tree (void)
 	    base = p->vma ? p->vma : exp_nameop (NAME, ".");
 
 	  lang_enter_output_section_statement (p->name, base,
-					       p->ok_to_load ? normal_section : noload_section,
-					       align, subalign, NULL, 0, 0);
+	    p->ok_to_load ? normal_section : noload_section, 0,
+	    align, subalign, NULL, 0, 0);
 	  base = 0;
 	  tmp = (struct wildcard_list *) xmalloc (sizeof *tmp);
 	  tmp->next = NULL;
diff --git a/ld/testsuite/ld-scripts/output-section-types.d b/ld/testsuite/ld-scripts/output-section-types.d
index ab124fa4dd7..2ecacaba57d 100644
--- a/ld/testsuite/ld-scripts/output-section-types.d
+++ b/ld/testsuite/ld-scripts/output-section-types.d
@@ -1,13 +1,17 @@
 #ld: -Toutput-section-types.t
 #source: align2a.s
-#objdump: -h
+#readelf: -S --wide
 #target: [is_elf_format]
 
 #...
-  . \.rom.*
-[ 	]+ALLOC, READONLY
-  . \.ro.*
-[ 	]+CONTENTS, ALLOC, LOAD, READONLY, DATA
-  . \.over.*
-[ 	]+CONTENTS, READONLY
+.* .rom          +NOBITS        +[0-9a-f]+ +[0-9a-f]+ +[0-9a-f]+ +00 +A +0 +0 +[1248]
+.* .ro           +PROGBITS      +[0-9a-f]+ +[0-9a-f]+ +[0-9a-f]+ +00 +A +0 +0 +[1248]
+.* .over         +PROGBITS      +[0-9a-f]+ +[0-9a-f]+ +[0-9a-f]+ +00  + +0 +0 +[1248]
+.* progbits      +PROGBITS      +[0-9a-f]+ +[0-9a-f]+ +[0-9a-f]+ +00 +A +0 +0 +[1248]
+.* strtab        +STRTAB        +[0-9a-f]+ +[0-9a-f]+ +[0-9a-f]+ +00 +A +0 +0 +[1248]
+.* note          +NOTE          +[0-9a-f]+ +[0-9a-f]+ +[0-9a-f]+ +00 +A +0 +0 +[1248]
+.* init_array    +INIT_ARRAY    +[0-9a-f]+ +[0-9a-f]+ +[0-9a-f]+ +0[48] +A +0 +0 +[1248]
+.* fini_array    +FINI_ARRAY    +[0-9a-f]+ +[0-9a-f]+ +[0-9a-f]+ +0[48] +A +0 +0 +[1248]
+.* preinit_array +PREINIT_ARRAY +[0-9a-f]+ +[0-9a-f]+ +[0-9a-f]+ +0[48] +A +0 +0 +[1248]
+.* .ro.note      +NOTE          +[0-9a-f]+ +[0-9a-f]+ +[0-9a-f]+ +00 +A +0 +0 +[1248]
 #pass
diff --git a/ld/testsuite/ld-scripts/output-section-types.t b/ld/testsuite/ld-scripts/output-section-types.t
index d8fdfda1a03..18fc5c11980 100644
--- a/ld/testsuite/ld-scripts/output-section-types.t
+++ b/ld/testsuite/ld-scripts/output-section-types.t
@@ -2,6 +2,13 @@ SECTIONS {
   .rom  (NOLOAD)   : { LONG(1234); }
   .ro   (READONLY) : { LONG(5678); }
   .over (OVERLAY)  : { LONG(0123); }
+  progbits (TYPE=SHT_PROGBITS) : { BYTE(1) }
+  strtab (TYPE = SHT_STRTAB) : { BYTE(0) }
+  note (TYPE =SHT_NOTE) : { BYTE(8) }
+  init_array (TYPE= 14) : { QUAD(14) }
+  fini_array ( TYPE=SHT_FINI_ARRAY) : { QUAD(15) }
+  preinit_array (TYPE=SHT_PREINIT_ARRAY ) : { QUAD(16) }
+  .ro.note   (READONLY (TYPE=SHT_NOTE)) : { LONG(5678); }
   /DISCARD/        : { *(*) }
 
 }

Re: Output section type (READONLY)

[Luca Boccassi]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Wed, 2022-02-16 at 17:38 +0000, Nick Clifton wrote:
>   Hi Guys,
> 
>    I have gone ahead and applied an update form of Fanguri's patch (attached).
> 
>    I extended the patch so that READONLY and type=<typename> can be used together
>    if desired, like this:
> 
>      .ro.note   (READONLY (TYPE=SHT_NOTE)) : { LONG(5678); }
> 
>    (I chose this particular syntax because it was the easiest to implement.
> 
>    Other than that the patch retains all of the features in the original submission:
> 
> https://sourceware.org/pipermail/binutils/2022-February/119600.html
> 
> Cheers
>    Nick

Thank you, looks great - tested on my side and it works like a charm.

-- 
Kind regards,
Luca Boccassi

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Output section type (READONLY)

[Fangrui Song]

On 2022-02-16, Nick Clifton wrote:
> Hi Guys,
>
>  I have gone ahead and applied an update form of Fanguri's patch (attached).

Thanks, this enables a proper way to set the section type in the future.
Hope someone implements this for gold as well since it does not
recognize .note* as SHT_NOTE, either.

>  I extended the patch so that READONLY and type=<typename> can be used together
>  if desired, like this:
>
>    .ro.note   (READONLY (TYPE=SHT_NOTE)) : { LONG(5678); }

... But I am a little bit uneasy with the additional support for READONLY.
Michael's comment (https://sourceware.org/pipermail/binutils/2022-February/119627.html) makes a lot of sense to me
and I think we really need evidence that (READONLY) is needed and worth
adding this syntax to support it...

>  (I chose this particular syntax because it was the easiest to implement.
>
>  Other than that the patch retains all of the features in the original submission:
>
>https://sourceware.org/pipermail/binutils/2022-February/119600.html
>
>Cheers
>  Nick

In addition, as mentioned on
https://bugzilla.redhat.com/show_bug.cgi?id=2052801 ideally when the
output section contains an input section of a different type, ld should
report a type mismatch error to prevent misuse, but I don't know how...

Re: Output section type (READONLY)

[Alan Modra]

On Wed, Feb 16, 2022 at 06:12:19PM -0800, Fangrui Song wrote:
> On 2022-02-16, Nick Clifton wrote:
> > Hi Guys,
> > 
> >  I have gone ahead and applied an update form of Fanguri's patch (attached).
> 
> Thanks, this enables a proper way to set the section type in the future.
> Hope someone implements this for gold as well since it does not
> recognize .note* as SHT_NOTE, either.

"DO NOT EDIT!" says the comment at the top of bfd-in2.h.  Move the new
type field where it belongs.

	PR ld/28841
	* section.c (struct bfd_section): Add type.  Formatting.
	(BFD_FAKE_SECTION): Formatting.
	* bfd-in2.h: Regenerate.

diff --git a/bfd/bfd-in2.h b/bfd/bfd-in2.h
index 78a0a1dea42..db41e7eb7fe 100644
--- a/bfd/bfd-in2.h
+++ b/bfd/bfd-in2.h
@@ -1166,11 +1166,13 @@ typedef struct bfd_section
     struct bfd_section *s;
     const char *linked_to_symbol_name;
   } map_head, map_tail;
- /* Points to the output section this section is already assigned to, if any.
-    This is used when support for non-contiguous memory regions is enabled.  */
- struct bfd_section *already_assigned;
 
-  /* Explicitly specified section type, if non-zero. */
+  /* Points to the output section this section is already assigned to,
+     if any.  This is used when support for non-contiguous memory
+     regions is enabled.  */
+  struct bfd_section *already_assigned;
+
+  /* Explicitly specified section type, if non-zero.  */
   unsigned int type;
 
 } asection;
@@ -1356,7 +1358,7 @@ discarded_section (const asection *sec)
      (struct bfd_symbol *) SYM, &SEC.symbol,                           \
                                                                        \
   /* map_head, map_tail, already_assigned, type                     */ \
-     { NULL }, { NULL }, NULL, 0                                       \
+     { NULL }, { NULL }, NULL,             0                           \
                                                                        \
     }
 
diff --git a/bfd/section.c b/bfd/section.c
index 2de7dbf661a..9a1071454f5 100644
--- a/bfd/section.c
+++ b/bfd/section.c
@@ -551,9 +551,14 @@ CODE_FRAGMENT
 .    struct bfd_section *s;
 .    const char *linked_to_symbol_name;
 .  } map_head, map_tail;
-. {* Points to the output section this section is already assigned to, if any.
-.    This is used when support for non-contiguous memory regions is enabled.  *}
-. struct bfd_section *already_assigned;
+.
+.  {* Points to the output section this section is already assigned to,
+.     if any.  This is used when support for non-contiguous memory
+.     regions is enabled.  *}
+.  struct bfd_section *already_assigned;
+.
+.  {* Explicitly specified section type, if non-zero.  *}
+.  unsigned int type;
 .
 .} asection;
 .
@@ -738,7 +743,7 @@ CODE_FRAGMENT
 .     (struct bfd_symbol *) SYM, &SEC.symbol,				\
 .									\
 .  {* map_head, map_tail, already_assigned, type                     *}	\
-.     { NULL }, { NULL }, NULL, 0						\
+.     { NULL }, { NULL }, NULL,             0				\
 .									\
 .    }
 .

-- 
Alan Modra
Australia Development Lab, IBM

Re: Output section type (READONLY)

[Fangrui Song]

Thanks!

On Mon, Feb 21, 2022, 15:04 Alan Modra <amodra@gmail.com> wrote:

> On Wed, Feb 16, 2022 at 06:12:19PM -0800, Fangrui Song wrote:
> > On 2022-02-16, Nick Clifton wrote:
> > > Hi Guys,
> > >
> > >  I have gone ahead and applied an update form of Fanguri's patch
> (attached).
> >
> > Thanks, this enables a proper way to set the section type in the future.
> > Hope someone implements this for gold as well since it does not
> > recognize .note* as SHT_NOTE, either.
>
> "DO NOT EDIT!" says the comment at the top of bfd-in2.h.  Move the new
> type field where it belongs.
>
>         PR ld/28841
>         * section.c (struct bfd_section): Add type.  Formatting.
>         (BFD_FAKE_SECTION): Formatting.
>         * bfd-in2.h: Regenerate.
>
> diff --git a/bfd/bfd-in2.h b/bfd/bfd-in2.h
> index 78a0a1dea42..db41e7eb7fe 100644
> --- a/bfd/bfd-in2.h
> +++ b/bfd/bfd-in2.h
> @@ -1166,11 +1166,13 @@ typedef struct bfd_section
>      struct bfd_section *s;
>      const char *linked_to_symbol_name;
>    } map_head, map_tail;
> - /* Points to the output section this section is already assigned to, if
> any.
> -    This is used when support for non-contiguous memory regions is
> enabled.  */
> - struct bfd_section *already_assigned;
>
> -  /* Explicitly specified section type, if non-zero. */
> +  /* Points to the output section this section is already assigned to,
> +     if any.  This is used when support for non-contiguous memory
> +     regions is enabled.  */
> +  struct bfd_section *already_assigned;
> +
> +  /* Explicitly specified section type, if non-zero.  */
>    unsigned int type;
>
>  } asection;
> @@ -1356,7 +1358,7 @@ discarded_section (const asection *sec)
>       (struct bfd_symbol *) SYM, &SEC.symbol,                           \
>                                                                         \
>    /* map_head, map_tail, already_assigned, type                     */ \
> -     { NULL }, { NULL }, NULL, 0                                       \
> +     { NULL }, { NULL }, NULL,             0                           \
>                                                                         \
>      }
>
> diff --git a/bfd/section.c b/bfd/section.c
> index 2de7dbf661a..9a1071454f5 100644
> --- a/bfd/section.c
> +++ b/bfd/section.c
> @@ -551,9 +551,14 @@ CODE_FRAGMENT
>  .    struct bfd_section *s;
>  .    const char *linked_to_symbol_name;
>  .  } map_head, map_tail;
> -. {* Points to the output section this section is already assigned to, if
> any.
> -.    This is used when support for non-contiguous memory regions is
> enabled.  *}
> -. struct bfd_section *already_assigned;
> +.
> +.  {* Points to the output section this section is already assigned to,
> +.     if any.  This is used when support for non-contiguous memory
> +.     regions is enabled.  *}
> +.  struct bfd_section *already_assigned;
> +.
> +.  {* Explicitly specified section type, if non-zero.  *}
> +.  unsigned int type;
>  .
>  .} asection;
>  .
> @@ -738,7 +743,7 @@ CODE_FRAGMENT
>  .     (struct bfd_symbol *) SYM, &SEC.symbol,                          \
>  .                                                                      \
>  .  {* map_head, map_tail, already_assigned, type                     *}
>       \
> -.     { NULL }, { NULL }, NULL, 0
>       \
> +.     { NULL }, { NULL }, NULL,             0                          \
>  .                                                                      \
>  .    }
>  .
>
> --
> Alan Modra
> Australia Development Lab, IBM
>