* Output section type (READONLY) @ 2022-01-29 7:45 Fangrui Song 2022-01-29 16:46 ` Luca Boccassi 2022-01-31 13:33 ` Nick Clifton 0 siblings, 2 replies; 15+ messages in thread From: Fangrui Song @ 2022-01-29 7:45 UTC (permalink / raw) To: Alan Modra, Nick Clifton; +Cc: binutils, Luca Boccassi [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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: Output section type (READONLY) 2022-01-29 7:45 Output section type (READONLY) Fangrui Song @ 2022-01-29 16:46 ` Luca Boccassi 2022-01-29 18:51 ` Fangrui Song 2022-01-31 13:33 ` Nick Clifton 1 sibling, 1 reply; 15+ messages in thread From: Luca Boccassi @ 2022-01-29 16:46 UTC (permalink / raw) To: binutils [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: Output section type (READONLY) 2022-01-29 16:46 ` Luca Boccassi @ 2022-01-29 18:51 ` Fangrui Song 0 siblings, 0 replies; 15+ messages in thread From: Fangrui Song @ 2022-01-29 18:51 UTC (permalink / raw) To: Luca Boccassi; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Output section type (READONLY) 2022-01-29 7:45 Output section type (READONLY) Fangrui Song 2022-01-29 16:46 ` Luca Boccassi @ 2022-01-31 13:33 ` Nick Clifton 2022-02-01 3:39 ` Fangrui Song 1 sibling, 1 reply; 15+ messages in thread From: Nick Clifton @ 2022-01-31 13:33 UTC (permalink / raw) To: Fangrui Song, Alan Modra; +Cc: binutils, Luca Boccassi 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Output section type (READONLY) 2022-01-31 13:33 ` Nick Clifton @ 2022-02-01 3:39 ` Fangrui Song 2022-02-01 11:07 ` Nick Clifton 0 siblings, 1 reply; 15+ messages in thread From: Fangrui Song @ 2022-02-01 3:39 UTC (permalink / raw) To: Nick Clifton; +Cc: Alan Modra, binutils, Luca Boccassi 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 > > > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Output section type (READONLY) 2022-02-01 3:39 ` Fangrui Song @ 2022-02-01 11:07 ` Nick Clifton 2022-02-01 11:59 ` Luca Boccassi 0 siblings, 1 reply; 15+ messages in thread From: Nick Clifton @ 2022-02-01 11:07 UTC (permalink / raw) To: Fangrui Song; +Cc: Alan Modra, binutils, Luca Boccassi 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: Output section type (READONLY) 2022-02-01 11:07 ` Nick Clifton @ 2022-02-01 11:59 ` Luca Boccassi 2022-02-02 7:29 ` Fangrui Song 0 siblings, 1 reply; 15+ messages in thread From: Luca Boccassi @ 2022-02-01 11:59 UTC (permalink / raw) To: binutils [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Output section type (READONLY) 2022-02-01 11:59 ` Luca Boccassi @ 2022-02-02 7:29 ` Fangrui Song 2022-02-02 16:54 ` Michael Matz 0 siblings, 1 reply; 15+ messages in thread From: Fangrui Song @ 2022-02-02 7:29 UTC (permalink / raw) To: Luca Boccassi; +Cc: binutils, Alan Modra, Nick Clifton, Cary Coutant 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Output section type (READONLY) 2022-02-02 7:29 ` Fangrui Song @ 2022-02-02 16:54 ` Michael Matz 2022-02-02 18:12 ` Luca Boccassi 0 siblings, 1 reply; 15+ messages in thread From: Michael Matz @ 2022-02-02 16:54 UTC (permalink / raw) To: Fangrui Song; +Cc: Luca Boccassi, binutils 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Output section type (READONLY) 2022-02-02 16:54 ` Michael Matz @ 2022-02-02 18:12 ` Luca Boccassi 2022-02-16 17:38 ` Nick Clifton 0 siblings, 1 reply; 15+ messages in thread From: Luca Boccassi @ 2022-02-02 18:12 UTC (permalink / raw) To: Michael Matz; +Cc: binutils, Fangrui Song [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Output section type (READONLY) 2022-02-02 18:12 ` Luca Boccassi @ 2022-02-16 17:38 ` Nick Clifton 2022-02-16 19:03 ` Luca Boccassi 2022-02-17 2:12 ` Fangrui Song 0 siblings, 2 replies; 15+ messages in thread From: Nick Clifton @ 2022-02-16 17:38 UTC (permalink / raw) To: Luca Boccassi, Michael Matz, Fangrui Song; +Cc: binutils [-- 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/ : { *(*) } } ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Output section type (READONLY) 2022-02-16 17:38 ` Nick Clifton @ 2022-02-16 19:03 ` Luca Boccassi 2022-02-17 2:12 ` Fangrui Song 1 sibling, 0 replies; 15+ messages in thread From: Luca Boccassi @ 2022-02-16 19:03 UTC (permalink / raw) To: Nick Clifton, Michael Matz, Fangrui Song; +Cc: binutils [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Output section type (READONLY) 2022-02-16 17:38 ` Nick Clifton 2022-02-16 19:03 ` Luca Boccassi @ 2022-02-17 2:12 ` Fangrui Song 2022-02-21 23:04 ` Alan Modra 1 sibling, 1 reply; 15+ messages in thread From: Fangrui Song @ 2022-02-17 2:12 UTC (permalink / raw) To: Nick Clifton; +Cc: Luca Boccassi, Michael Matz, binutils 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... ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Output section type (READONLY) 2022-02-17 2:12 ` Fangrui Song @ 2022-02-21 23:04 ` Alan Modra 2022-02-21 23:30 ` Fangrui Song 0 siblings, 1 reply; 15+ messages in thread From: Alan Modra @ 2022-02-21 23:04 UTC (permalink / raw) To: Fangrui Song; +Cc: Nick Clifton, binutils, Luca Boccassi 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Output section type (READONLY) 2022-02-21 23:04 ` Alan Modra @ 2022-02-21 23:30 ` Fangrui Song 0 siblings, 0 replies; 15+ messages in thread From: Fangrui Song @ 2022-02-21 23:30 UTC (permalink / raw) To: Alan Modra; +Cc: Nick Clifton, binutils, Luca Boccassi 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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2022-02-21 23:37 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-29 7:45 Output section type (READONLY) Fangrui Song 2022-01-29 16:46 ` Luca Boccassi 2022-01-29 18:51 ` Fangrui Song 2022-01-31 13:33 ` Nick Clifton 2022-02-01 3:39 ` Fangrui Song 2022-02-01 11:07 ` Nick Clifton 2022-02-01 11:59 ` Luca Boccassi 2022-02-02 7:29 ` Fangrui Song 2022-02-02 16:54 ` Michael Matz 2022-02-02 18:12 ` Luca Boccassi 2022-02-16 17:38 ` Nick Clifton 2022-02-16 19:03 ` Luca Boccassi 2022-02-17 2:12 ` Fangrui Song 2022-02-21 23:04 ` Alan Modra 2022-02-21 23:30 ` Fangrui Song
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).