* .section directives with the same name but different fields @ 2020-02-06 7:38 Fangrui Song 2020-02-06 8:33 ` Alan Modra 0 siblings, 1 reply; 12+ messages in thread From: Fangrui Song @ 2020-02-06 7:38 UTC (permalink / raw) To: binutils; +Cc: bd1976llvm ## Different group signature .section .foo,"aG",@progbits,foo .section .foo,"aG",@progbits,bar Both GNU as and llvm-mc (usage: llvm-mc -filetype=obj a.s -o a.o) create two sections. We don't want to change this rule. ## Different sh_link foo: bar: .section .foo,"ao",@progbits,foo .section .foo,"ao",@progbits,bar With H.J. Lu's https://sourceware.org/ml/binutils/2020-02/msg00028.html , GNU as emits two sections, even if foo and bar are defined in the same section. This is something both GNU as and llvm-mc (https://reviews.llvm.org/D74006) want to do. Also see https://bugs.llvm.org/show_bug.cgi?id=44775 Now, something that needs discussion. ## Different sh_entsize .section .foo,"aM",@progbits,4 .section .foo,"aM",@progbits,8 GNU as emits a warning `Warning: ignoring changed section entity size for .foo` The output sh_entsize is 4. If the second .section defines an object, the object may get corrupted after merging (https://bugs.llvm.org/show_bug.cgi?id=43457 ) For this case, we have several choices: 1. (Status quo) Emit one section. Set sh_entsize to 4 and emit a warning. 2. Emit two sections, i.e. sh_entsize is a differentiator. 3. Emit one section. Set sh_entsize to 0. Should the assembler emit a warning? ## Different sh_flags .section .foo,"aw" .section .foo,"a" # Warning: ignoring changed section attributes for .foo Shall we emit two sections? ## Different sh_type .section .foo,"a",@progbits .section .foo,"a",@nobits # Warning: ignoring changed section type for .foo Shall we emit two sections? ## Different sh_addr,sh_offset,sh_size,sh_info,sh_addralign These fields are not specified by the .section directive, thus they should not be a differentiator. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: .section directives with the same name but different fields 2020-02-06 7:38 .section directives with the same name but different fields Fangrui Song @ 2020-02-06 8:33 ` Alan Modra 2020-02-06 9:19 ` Fangrui Song 0 siblings, 1 reply; 12+ messages in thread From: Alan Modra @ 2020-02-06 8:33 UTC (permalink / raw) To: Fangrui Song; +Cc: binutils, bd1976llvm On Wed, Feb 05, 2020 at 11:38:37PM -0800, Fangrui Song wrote: > ## Different sh_entsize > > .section .foo,"aM",@progbits,4 > .section .foo,"aM",@progbits,8 > > GNU as emits a warning `Warning: ignoring changed section entity size for .foo` I think this one probably should be an error rather than a warning. > The output sh_entsize is 4. If the second .section defines an object, the object may get corrupted after merging > (https://bugs.llvm.org/show_bug.cgi?id=43457 ) > For this case, we have several choices: > > 1. (Status quo) Emit one section. Set sh_entsize to 4 and emit a warning. > 2. Emit two sections, i.e. sh_entsize is a differentiator. If you do, the linker won't do merging of values for those sections. > 3. Emit one section. Set sh_entsize to 0. Should the assembler emit a warning? And remove SHF_MERGE too I guess. That's an option but I think it's better just to error. > > ## Different sh_flags > > .section .foo,"aw" > .section .foo,"a" # Warning: ignoring changed section attributes for .foo > > Shall we emit two sections? I don't think so. User assembly often gets section attributes wrong or leaves them off entirely for special sections known to the assembler. ie. the first .section .foo above is a built-in rather than user input. > > ## Different sh_type > > .section .foo,"a",@progbits > .section .foo,"a",@nobits # Warning: ignoring changed section type for .foo > > Shall we emit two sections? Again we should continue to handle the case where .foo is a special section of known type. So I think a warning rather than creating two sections is appropriate. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: .section directives with the same name but different fields 2020-02-06 8:33 ` Alan Modra @ 2020-02-06 9:19 ` Fangrui Song 2020-02-06 14:09 ` Alan Modra 0 siblings, 1 reply; 12+ messages in thread From: Fangrui Song @ 2020-02-06 9:19 UTC (permalink / raw) To: Alan Modra; +Cc: binutils, bd1976llvm On 2020-02-06, Alan Modra wrote: >On Wed, Feb 05, 2020@11:38:37PM -0800, Fangrui Song wrote: >> ## Different sh_entsize >> >> .section .foo,"aM",@progbits,4 >> .section .foo,"aM",@progbits,8 >> >> GNU as emits a warning `Warning: ignoring changed section entity size for .foo` > >I think this one probably should be an error rather than a warning. An error is fine, but it can bring up some implementation difficulties. If an implementation does a one-pass scan over global variables to emit .section directives and variable labels, it may not know sh_entsize when it is about the emit the first .section directive. >> The output sh_entsize is 4. If the second .section defines an object, the object may get corrupted after merging >> (https://bugs.llvm.org/show_bug.cgi?id=43457 ) >> For this case, we have several choices: >> >> 1. (Status quo) Emit one section. Set sh_entsize to 4 and emit a warning. >> 2. Emit two sections, i.e. sh_entsize is a differentiator. > >If you do, the linker won't do merging of values for those sections. > >> 3. Emit one section. Set sh_entsize to 0. Should the assembler emit a warning? > >And remove SHF_MERGE too I guess. That's an option but I think it's >better just to error. > >> >> ## Different sh_flags >> >> .section .foo,"aw" >> .section .foo,"a" # Warning: ignoring changed section attributes for .foo >> >> Shall we emit two sections? > >I don't think so. User assembly often gets section attributes wrong >or leaves them off entirely for special sections known to the >assembler. ie. the first .section .foo above is a built-in rather >than user input. > >> >> ## Different sh_type >> >> .section .foo,"a",@progbits >> .section .foo,"a",@nobits # Warning: ignoring changed section type for .foo >> >> Shall we emit two sections? > >Again we should continue to handle the case where .foo is a special >section of known type. So I think a warning rather than creating two >sections is appropriate. Do you think the warnings should be upgraded to errors (for sh_flags and sh_type)? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: .section directives with the same name but different fields 2020-02-06 9:19 ` Fangrui Song @ 2020-02-06 14:09 ` Alan Modra 2020-02-06 17:25 ` bd1976 llvm 0 siblings, 1 reply; 12+ messages in thread From: Alan Modra @ 2020-02-06 14:09 UTC (permalink / raw) To: Fangrui Song; +Cc: binutils, bd1976llvm On Thu, Feb 06, 2020 at 01:19:14AM -0800, Fangrui Song wrote: > On 2020-02-06, Alan Modra wrote: > > On Wed, Feb 05, 2020@11:38:37PM -0800, Fangrui Song wrote: > > > ## Different sh_entsize > > > > > > .section .foo,"aM",@progbits,4 > > > .section .foo,"aM",@progbits,8 > > > > > > GNU as emits a warning `Warning: ignoring changed section entity size for .foo` > > > > I think this one probably should be an error rather than a warning. > > An error is fine, but it can bring up some implementation difficulties. > If an implementation does a one-pass scan over global variables to > emit .section directives and variable labels, it may not know sh_entsize > when it is about the emit the first .section directive. > > > > The output sh_entsize is 4. If the second .section defines an object, the object may get corrupted after merging > > > (https://bugs.llvm.org/show_bug.cgi?id=43457 ) > > > For this case, we have several choices: > > > > > > 1. (Status quo) Emit one section. Set sh_entsize to 4 and emit a warning. > > > 2. Emit two sections, i.e. sh_entsize is a differentiator. > > > > If you do, the linker won't do merging of values for those sections. > > > > > 3. Emit one section. Set sh_entsize to 0. Should the assembler emit a warning? > > > > And remove SHF_MERGE too I guess. That's an option but I think it's > > better just to error. > > > > > > > > ## Different sh_flags > > > > > > .section .foo,"aw" > > > .section .foo,"a" # Warning: ignoring changed section attributes for .foo > > > > > > Shall we emit two sections? > > > > I don't think so. User assembly often gets section attributes wrong > > or leaves them off entirely for special sections known to the > > assembler. ie. the first .section .foo above is a built-in rather > > than user input. > > > > > > > > ## Different sh_type > > > > > > .section .foo,"a",@progbits > > > .section .foo,"a",@nobits # Warning: ignoring changed section type for .foo > > > > > > Shall we emit two sections? > > > > Again we should continue to handle the case where .foo is a special > > section of known type. So I think a warning rather than creating two > > sections is appropriate. > > Do you think the warnings should be upgraded to errors (for sh_flags and > sh_type)? No. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: .section directives with the same name but different fields 2020-02-06 14:09 ` Alan Modra @ 2020-02-06 17:25 ` bd1976 llvm 2020-02-10 5:21 ` Alan Modra 0 siblings, 1 reply; 12+ messages in thread From: bd1976 llvm @ 2020-02-06 17:25 UTC (permalink / raw) To: Alan Modra; +Cc: Fangrui Song, binutils On Thu, Feb 6, 2020 at 2:09 PM Alan Modra <amodra@gmail.com> wrote: > On Thu, Feb 06, 2020 at 01:19:14AM -0800, Fangrui Song wrote: > > On 2020-02-06, Alan Modra wrote: > > > On Wed, Feb 05, 2020@11:38:37PM -0800, Fangrui Song wrote: > > > > ## Different sh_entsize > > > > > > > > .section .foo,"aM",@progbits,4 > > > > .section .foo,"aM",@progbits,8 > > > > > > > > GNU as emits a warning `Warning: ignoring changed section entity > size for .foo` > > > > > > I think this one probably should be an error rather than a warning. > > > > An error is fine, but it can bring up some implementation difficulties. > > If an implementation does a one-pass scan over global variables to > > emit .section directives and variable labels, it may not know sh_entsize > > when it is about the emit the first .section directive. > > > > > > The output sh_entsize is 4. If the second .section defines an > object, the object may get corrupted after merging > > > > (https://bugs.llvm.org/show_bug.cgi?id=43457 ) > > > > For this case, we have several choices: > > > > > > > > 1. (Status quo) Emit one section. Set sh_entsize to 4 and emit a > warning. > > > > 2. Emit two sections, i.e. sh_entsize is a differentiator. > > > > > > If you do, the linker won't do merging of values for those sections. > > > > > > > 3. Emit one section. Set sh_entsize to 0. Should the assembler emit > a warning? > > > > > > And remove SHF_MERGE too I guess. That's an option but I think it's > > > better just to error. > > > > > > > > > > > ## Different sh_flags > > > > > > > > .section .foo,"aw" > > > > .section .foo,"a" # Warning: ignoring changed section attributes for > .foo > > > > > > > > Shall we emit two sections? > > > > > > I don't think so. User assembly often gets section attributes wrong > > > or leaves them off entirely for special sections known to the > > > assembler. ie. the first .section .foo above is a built-in rather > > > than user input. > > > > > > > > > > > ## Different sh_type > > > > > > > > .section .foo,"a",@progbits > > > > .section .foo,"a",@nobits # Warning: ignoring changed section type > for .foo > > > > > > > > Shall we emit two sections? > > > > > > Again we should continue to handle the case where .foo is a special > > > section of known type. So I think a warning rather than creating two > > > sections is appropriate. > > > > Do you think the warnings should be upgraded to errors (for sh_flags and > > sh_type)? > > No. > > Hi Alan, thanks for the input here. I wonder if it wouldn't be more consistent to error in all cases - even in the case of different group signatures. The only exception would need to be for the special section names (.text, .debug_str, etc...) that the assembler has special knowledge of (as you explained). I wonder why creating multiple sections with the same name for section directives with different group signatures was implemented - why not just require the use of a distinct section name for these? Or, now that GNU has the ",unique,N" assembly extension ( https://sourceware.org/ml/binutils/2020-02/msg00028.html) that could be used if the section name is fixed - it would then be explicit in the source code that another section with the same name will be created. To be clear, currently I have to remember that.. .section .foo,"aG",@progbits,foo .section .foo,"aG",@progbits,bar ..results in two sections implicitly. Whereas if I was required to use different section names.. .section .foo.foo,"aG",@progbits,foo .section .foo.bar,"aG",@progbits,bar ..or the unique extension.. .section .foo,"aG",@progbits,foo,comdat,unique,1 .section .foo,"aG",@progbits,bar,comdat,unique,2 .. then it is clear (IMO) that multiple sections will be generated. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: .section directives with the same name but different fields 2020-02-06 17:25 ` bd1976 llvm @ 2020-02-10 5:21 ` Alan Modra 2020-03-03 21:20 ` Empty section flags Fangrui Song [not found] ` <CAN30aBGpQecmszv-JsZwVTNrOTW0dGt4zUjas7Cx6b-B3XwjgQ@mail.gmail.com> 0 siblings, 2 replies; 12+ messages in thread From: Alan Modra @ 2020-02-10 5:21 UTC (permalink / raw) To: bd1976 llvm; +Cc: Fangrui Song, binutils On Thu, Feb 06, 2020 at 05:25:33PM +0000, bd1976 llvm wrote: > Hi Alan, thanks for the input here. I wonder if it wouldn't be more > consistent to error in all cases - even in the case of different group > signatures. The only exception would need to be for the special section > names (.text, .debug_str, etc...) that the assembler has special knowledge > of (as you explained). Yes, let's see how that goes. https://sourceware.org/ml/binutils/2020-02/msg00129.html > I wonder why creating multiple sections with the > same name for section directives with different group signatures was > implemented - why not just require the use of a distinct section name for > these? I think plain ".text" for a group's text section is fine. Distict names would just be yet another thing to track for a group. > Or, now that GNU has the ",unique,N" assembly extension ( > https://sourceware.org/ml/binutils/2020-02/msg00028.html) that could be > used if the section name is fixed - it would then be explicit in the source > code that another section with the same name will be created. Perhaps, but we aren't designing a new toolchain. Backwards compatibility can't be discarded without compelling reasons. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 12+ messages in thread
* Empty section flags 2020-02-10 5:21 ` Alan Modra @ 2020-03-03 21:20 ` Fangrui Song 2020-04-04 14:17 ` H.J. Lu [not found] ` <CAN30aBGpQecmszv-JsZwVTNrOTW0dGt4zUjas7Cx6b-B3XwjgQ@mail.gmail.com> 1 sibling, 1 reply; 12+ messages in thread From: Fangrui Song @ 2020-03-03 21:20 UTC (permalink / raw) To: Alan Modra; +Cc: bd1976 llvm, binutils On Sun, Feb 9, 2020 at 9:21 PM Alan Modra <amodra@gmail.com> wrote: > > On Thu, Feb 06, 2020 at 05:25:33PM +0000, bd1976 llvm wrote: > > Hi Alan, thanks for the input here. I wonder if it wouldn't be more > > consistent to error in all cases - even in the case of different group > > signatures. The only exception would need to be for the special section > > names (.text, .debug_str, etc...) that the assembler has special knowledge > > of (as you explained). > > Yes, let's see how that goes. > https://sourceware.org/ml/binutils/2020-02/msg00129.html > > > I wonder why creating multiple sections with the > > same name for section directives with different group signatures was > > implemented - why not just require the use of a distinct section name for > > these? > > I think plain ".text" for a group's text section is fine. Distict > names would just be yet another thing to track for a group. > > > Or, now that GNU has the ",unique,N" assembly extension ( > > https://sourceware.org/ml/binutils/2020-02/msg00028.html) that could be > > used if the section name is fixed - it would then be explicit in the source > > code that another section with the same name will be created. > > Perhaps, but we aren't designing a new toolchain. Backwards > compatibility can't be discarded without compelling reasons. > > -- > Alan Modra > Australia Development Lab, IBM For empty flags, should there be an error as well? .section .foo,"ax",@progbits; .byte 1 .section .foo,"",@progbits; .byte 2 # no diagnostic .section .foo,"a",@progbits; .byte 3 # Error: changed section attributes for .foo Context: https://github.com/ClangBuiltLinux/linux/issues/913 I lean toward an error for consistency, and I will try making the LLVM MC side rule stick. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Empty section flags 2020-03-03 21:20 ` Empty section flags Fangrui Song @ 2020-04-04 14:17 ` H.J. Lu 2020-04-04 16:38 ` Fangrui Song 0 siblings, 1 reply; 12+ messages in thread From: H.J. Lu @ 2020-04-04 14:17 UTC (permalink / raw) To: Fangrui Song; +Cc: Alan Modra, bd1976 llvm, Binutils On Tue, Mar 3, 2020 at 1:20 PM Fangrui Song <i@maskray.me> wrote: > > On Sun, Feb 9, 2020 at 9:21 PM Alan Modra <amodra@gmail.com> wrote: > > > > On Thu, Feb 06, 2020 at 05:25:33PM +0000, bd1976 llvm wrote: > > > Hi Alan, thanks for the input here. I wonder if it wouldn't be more > > > consistent to error in all cases - even in the case of different group > > > signatures. The only exception would need to be for the special section > > > names (.text, .debug_str, etc...) that the assembler has special knowledge > > > of (as you explained). > > > > Yes, let's see how that goes. > > https://sourceware.org/ml/binutils/2020-02/msg00129.html > > > > > I wonder why creating multiple sections with the > > > same name for section directives with different group signatures was > > > implemented - why not just require the use of a distinct section name for > > > these? > > > > I think plain ".text" for a group's text section is fine. Distict > > names would just be yet another thing to track for a group. > > > > > Or, now that GNU has the ",unique,N" assembly extension ( > > > https://sourceware.org/ml/binutils/2020-02/msg00028.html) that could be > > > used if the section name is fixed - it would then be explicit in the source > > > code that another section with the same name will be created. > > > > Perhaps, but we aren't designing a new toolchain. Backwards > > compatibility can't be discarded without compelling reasons. > > > > -- > > Alan Modra > > Australia Development Lab, IBM > > For empty flags, should there be an error as well? > > .section .foo,"ax",@progbits; .byte 1 > .section .foo,"",@progbits; .byte 2 # no diagnostic > .section .foo,"a",@progbits; .byte 3 # Error: changed section > attributes for .foo > > Context: https://github.com/ClangBuiltLinux/linux/issues/913 > > I lean toward an error for consistency, and I will try making the LLVM > MC side rule stick. [hjl@gnu-cfl-2 tmp]$ cat x.s .section .foo,"",@progbits; .byte 2 [hjl@gnu-cfl-2 tmp]$ gcc -c x.s [hjl@gnu-cfl-2 tmp]$ readelf -SW x.o | grep foo [ 4] .foo PROGBITS 0000000000000000 000040 000001 00 0 0 1 [hjl@gnu-cfl-2 tmp]$ Unless it is disallowed by gABI/psABI, assembler should allow it. Sometimes, I found a need to create odd object files, like zero-sized relocation section, for linker test. Assembler should have more flexibilities within gABI/psABI. -- H.J. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Empty section flags 2020-04-04 14:17 ` H.J. Lu @ 2020-04-04 16:38 ` Fangrui Song 2020-04-04 16:45 ` H.J. Lu 0 siblings, 1 reply; 12+ messages in thread From: Fangrui Song @ 2020-04-04 16:38 UTC (permalink / raw) To: H.J. Lu; +Cc: Alan Modra, bd1976 llvm, Binutils On 2020-04-04, H.J. Lu wrote: >On Tue, Mar 3, 2020 at 1:20 PM Fangrui Song <i@maskray.me> wrote: >> >> On Sun, Feb 9, 2020 at 9:21 PM Alan Modra <amodra@gmail.com> wrote: >> > >> > On Thu, Feb 06, 2020 at 05:25:33PM +0000, bd1976 llvm wrote: >> > > Hi Alan, thanks for the input here. I wonder if it wouldn't be more >> > > consistent to error in all cases - even in the case of different group >> > > signatures. The only exception would need to be for the special section >> > > names (.text, .debug_str, etc...) that the assembler has special knowledge >> > > of (as you explained). >> > >> > Yes, let's see how that goes. >> > https://sourceware.org/ml/binutils/2020-02/msg00129.html >> > >> > > I wonder why creating multiple sections with the >> > > same name for section directives with different group signatures was >> > > implemented - why not just require the use of a distinct section name for >> > > these? >> > >> > I think plain ".text" for a group's text section is fine. Distict >> > names would just be yet another thing to track for a group. >> > >> > > Or, now that GNU has the ",unique,N" assembly extension ( >> > > https://sourceware.org/ml/binutils/2020-02/msg00028.html) that could be >> > > used if the section name is fixed - it would then be explicit in the source >> > > code that another section with the same name will be created. >> > >> > Perhaps, but we aren't designing a new toolchain. Backwards >> > compatibility can't be discarded without compelling reasons. >> > >> > -- >> > Alan Modra >> > Australia Development Lab, IBM >> >> For empty flags, should there be an error as well? >> >> .section .foo,"ax",@progbits; .byte 1 >> .section .foo,"",@progbits; .byte 2 # no diagnostic >> .section .foo,"a",@progbits; .byte 3 # Error: changed section >> attributes for .foo >> >> Context: https://github.com/ClangBuiltLinux/linux/issues/913 >> >> I lean toward an error for consistency, and I will try making the LLVM >> MC side rule stick. > >[hjl@gnu-cfl-2 tmp]$ cat x.s >.section .foo,"",@progbits; .byte 2 >[hjl@gnu-cfl-2 tmp]$ gcc -c x.s >[hjl@gnu-cfl-2 tmp]$ readelf -SW x.o | grep foo > [ 4] .foo PROGBITS 0000000000000000 000040 >000001 00 0 0 1 >[hjl@gnu-cfl-2 tmp]$ > >Unless it is disallowed by gABI/psABI, assembler should allow it. >Sometimes, I found a need to create odd object files, like zero-sized >relocation section, for linker test. Assembler should have more >flexibilities within gABI/psABI. > >-- >H.J. Declaring a section with empty flags is fine. My question is about re-declaring with empty flags when the first declaration has other flags: .section .foo,"ax",@progbits; .byte 1 .section .foo,"",@progbits; .byte 2 # no diagnostic .section .foo,"a",@progbits; .byte 3 # Error: changed section This is about the follow-up of https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=33176d912add7680277ad5e18af0e6303d9a7af8 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Empty section flags 2020-04-04 16:38 ` Fangrui Song @ 2020-04-04 16:45 ` H.J. Lu 2020-04-13 21:32 ` Fangrui Song 0 siblings, 1 reply; 12+ messages in thread From: H.J. Lu @ 2020-04-04 16:45 UTC (permalink / raw) To: Fangrui Song; +Cc: Alan Modra, bd1976 llvm, Binutils On Sat, Apr 4, 2020 at 9:38 AM Fangrui Song <i@maskray.me> wrote: > > On 2020-04-04, H.J. Lu wrote: > >On Tue, Mar 3, 2020 at 1:20 PM Fangrui Song <i@maskray.me> wrote: > >> > >> On Sun, Feb 9, 2020 at 9:21 PM Alan Modra <amodra@gmail.com> wrote: > >> > > >> > On Thu, Feb 06, 2020 at 05:25:33PM +0000, bd1976 llvm wrote: > >> > > Hi Alan, thanks for the input here. I wonder if it wouldn't be more > >> > > consistent to error in all cases - even in the case of different group > >> > > signatures. The only exception would need to be for the special section > >> > > names (.text, .debug_str, etc...) that the assembler has special knowledge > >> > > of (as you explained). > >> > > >> > Yes, let's see how that goes. > >> > https://sourceware.org/ml/binutils/2020-02/msg00129.html > >> > > >> > > I wonder why creating multiple sections with the > >> > > same name for section directives with different group signatures was > >> > > implemented - why not just require the use of a distinct section name for > >> > > these? > >> > > >> > I think plain ".text" for a group's text section is fine. Distict > >> > names would just be yet another thing to track for a group. > >> > > >> > > Or, now that GNU has the ",unique,N" assembly extension ( > >> > > https://sourceware.org/ml/binutils/2020-02/msg00028.html) that could be > >> > > used if the section name is fixed - it would then be explicit in the source > >> > > code that another section with the same name will be created. > >> > > >> > Perhaps, but we aren't designing a new toolchain. Backwards > >> > compatibility can't be discarded without compelling reasons. > >> > > >> > -- > >> > Alan Modra > >> > Australia Development Lab, IBM > >> > >> For empty flags, should there be an error as well? > >> > >> .section .foo,"ax",@progbits; .byte 1 > >> .section .foo,"",@progbits; .byte 2 # no diagnostic > >> .section .foo,"a",@progbits; .byte 3 # Error: changed section > >> attributes for .foo > >> > >> Context: https://github.com/ClangBuiltLinux/linux/issues/913 > >> > >> I lean toward an error for consistency, and I will try making the LLVM > >> MC side rule stick. > > > >[hjl@gnu-cfl-2 tmp]$ cat x.s > >.section .foo,"",@progbits; .byte 2 > >[hjl@gnu-cfl-2 tmp]$ gcc -c x.s > >[hjl@gnu-cfl-2 tmp]$ readelf -SW x.o | grep foo > > [ 4] .foo PROGBITS 0000000000000000 000040 > >000001 00 0 0 1 > >[hjl@gnu-cfl-2 tmp]$ > > > >Unless it is disallowed by gABI/psABI, assembler should allow it. > >Sometimes, I found a need to create odd object files, like zero-sized > >relocation section, for linker test. Assembler should have more > >flexibilities within gABI/psABI. > > > >-- > >H.J. > > Declaring a section with empty flags is fine. > My question is about re-declaring with empty flags when the first declaration has other flags: > > .section .foo,"ax",@progbits; .byte 1 > .section .foo,"",@progbits; .byte 2 # no diagnostic > .section .foo,"a",@progbits; .byte 3 # Error: changed section > > This is about the follow-up of > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=33176d912add7680277ad5e18af0e6303d9a7af8 [hjl@gnu-cfl-2 tmp]$ cat y.s .section .foo,"ax",@progbits .byte 1 .section .foo .byte 2 .section .foo,"",@progbits .byte 3 .section .foo,"ax" .byte 3 [hjl@gnu-cfl-2 tmp]$ gcc -c y.s [hjl@gnu-cfl-2 tmp]$ readelf -SW y.o | grep foo [ 4] .foo PROGBITS 0000000000000000 000040 000004 00 AX 0 0 1 [hjl@gnu-cfl-2 tmp]$ If section flags or type is unspecified/empty, GNU assembler uses the previous one if it exists. I think this behavior is quite reasonable. -- H.J. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Empty section flags 2020-04-04 16:45 ` H.J. Lu @ 2020-04-13 21:32 ` Fangrui Song 0 siblings, 0 replies; 12+ messages in thread From: Fangrui Song @ 2020-04-13 21:32 UTC (permalink / raw) To: H.J. Lu; +Cc: Alan Modra, bd1976 llvm, Binutils On 2020-04-04, H.J. Lu wrote: >On Sat, Apr 4, 2020 at 9:38 AM Fangrui Song <i@maskray.me> wrote: >> >> On 2020-04-04, H.J. Lu wrote: >> >On Tue, Mar 3, 2020 at 1:20 PM Fangrui Song <i@maskray.me> wrote: >> >> >> >> On Sun, Feb 9, 2020 at 9:21 PM Alan Modra <amodra@gmail.com> wrote: >> >> > >> >> > On Thu, Feb 06, 2020 at 05:25:33PM +0000, bd1976 llvm wrote: >> >> > > Hi Alan, thanks for the input here. I wonder if it wouldn't be more >> >> > > consistent to error in all cases - even in the case of different group >> >> > > signatures. The only exception would need to be for the special section >> >> > > names (.text, .debug_str, etc...) that the assembler has special knowledge >> >> > > of (as you explained). >> >> > >> >> > Yes, let's see how that goes. >> >> > https://sourceware.org/ml/binutils/2020-02/msg00129.html >> >> > >> >> > > I wonder why creating multiple sections with the >> >> > > same name for section directives with different group signatures was >> >> > > implemented - why not just require the use of a distinct section name for >> >> > > these? >> >> > >> >> > I think plain ".text" for a group's text section is fine. Distict >> >> > names would just be yet another thing to track for a group. >> >> > >> >> > > Or, now that GNU has the ",unique,N" assembly extension ( >> >> > > https://sourceware.org/ml/binutils/2020-02/msg00028.html) that could be >> >> > > used if the section name is fixed - it would then be explicit in the source >> >> > > code that another section with the same name will be created. >> >> > >> >> > Perhaps, but we aren't designing a new toolchain. Backwards >> >> > compatibility can't be discarded without compelling reasons. >> >> > >> >> > -- >> >> > Alan Modra >> >> > Australia Development Lab, IBM >> >> >> >> For empty flags, should there be an error as well? >> >> >> >> .section .foo,"ax",@progbits; .byte 1 >> >> .section .foo,"",@progbits; .byte 2 # no diagnostic >> >> .section .foo,"a",@progbits; .byte 3 # Error: changed section >> >> attributes for .foo >> >> >> >> Context: https://github.com/ClangBuiltLinux/linux/issues/913 >> >> >> >> I lean toward an error for consistency, and I will try making the LLVM >> >> MC side rule stick. >> > >> >[hjl@gnu-cfl-2 tmp]$ cat x.s >> >.section .foo,"",@progbits; .byte 2 >> >[hjl@gnu-cfl-2 tmp]$ gcc -c x.s >> >[hjl@gnu-cfl-2 tmp]$ readelf -SW x.o | grep foo >> > [ 4] .foo PROGBITS 0000000000000000 000040 >> >000001 00 0 0 1 >> >[hjl@gnu-cfl-2 tmp]$ >> > >> >Unless it is disallowed by gABI/psABI, assembler should allow it. >> >Sometimes, I found a need to create odd object files, like zero-sized >> >relocation section, for linker test. Assembler should have more >> >flexibilities within gABI/psABI. >> > >> >-- >> >H.J. >> >> Declaring a section with empty flags is fine. >> My question is about re-declaring with empty flags when the first declaration has other flags: >> >> .section .foo,"ax",@progbits; .byte 1 >> .section .foo,"",@progbits; .byte 2 # no diagnostic >> .section .foo,"a",@progbits; .byte 3 # Error: changed section >> >> This is about the follow-up of >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=33176d912add7680277ad5e18af0e6303d9a7af8 > >[hjl@gnu-cfl-2 tmp]$ cat y.s >.section .foo,"ax",@progbits >.byte 1 >.section .foo >.byte 2 >.section .foo,"",@progbits >.byte 3 >.section .foo,"ax" >.byte 3 >[hjl@gnu-cfl-2 tmp]$ gcc -c y.s >[hjl@gnu-cfl-2 tmp]$ readelf -SW y.o | grep foo > [ 4] .foo PROGBITS 0000000000000000 000040 >000004 00 AX 0 0 1 >[hjl@gnu-cfl-2 tmp]$ > >If section flags or type is unspecified/empty, GNU assembler uses the >previous one if it exists. I think this behavior is quite reasonable. > >-- >H.J. When sh_flags is unspecified, I can accept that it will use the previous one (ideally I hope it does not do this) .section .foo But when sh_flags is specified as an empty string, I find it quite unintuitive to be different from a non-empty string .section .foo,"" # different from .section .foo,"a" , which checks compatibility ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <CAN30aBGpQecmszv-JsZwVTNrOTW0dGt4zUjas7Cx6b-B3XwjgQ@mail.gmail.com>]
* Re: Empty section flags [not found] ` <CAN30aBGpQecmszv-JsZwVTNrOTW0dGt4zUjas7Cx6b-B3XwjgQ@mail.gmail.com> @ 2020-04-04 0:43 ` Fangrui Song 0 siblings, 0 replies; 12+ messages in thread From: Fangrui Song @ 2020-04-04 0:43 UTC (permalink / raw) To: Alan Modra; +Cc: bd1976 llvm, binutils On 2020-03-03, Fangrui Song wrote: >On Sun, Feb 9, 2020 at 9:21 PM Alan Modra <amodra@gmail.com> wrote: >> >> On Thu, Feb 06, 2020 at 05:25:33PM +0000, bd1976 llvm wrote: >> > Hi Alan, thanks for the input here. I wonder if it wouldn't be more >> > consistent to error in all cases - even in the case of different group >> > signatures. The only exception would need to be for the special section >> > names (.text, .debug_str, etc...) that the assembler has special knowledge >> > of (as you explained). >> >> Yes, let's see how that goes. >> https://sourceware.org/ml/binutils/2020-02/msg00129.html >> >> > I wonder why creating multiple sections with the >> > same name for section directives with different group signatures was >> > implemented - why not just require the use of a distinct section name for >> > these? >> >> I think plain ".text" for a group's text section is fine. Distict >> names would just be yet another thing to track for a group. >> >> > Or, now that GNU has the ",unique,N" assembly extension ( >> > https://sourceware.org/ml/binutils/2020-02/msg00028.html) that could be >> > used if the section name is fixed - it would then be explicit in the source >> > code that another section with the same name will be created. >> >> Perhaps, but we aren't designing a new toolchain. Backwards >> compatibility can't be discarded without compelling reasons. >> >> -- >> Alan Modra >> Australia Development Lab, IBM > >For empty flags, should there be an error as well? > > .section .foo,"ax",@progbits; .byte 1 > .section .foo,"",@progbits; .byte 2 # no diagnostic > .section .foo,"a",@progbits; .byte 3 # Error: changed section >attributes for .foo > >Context: https://github.com/ClangBuiltLinux/linux/issues/913 > >I lean toward an error for consistency, and I will try making the LLVM >MC side rule stick. Thoughts? :) ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-04-13 21:32 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-06 7:38 .section directives with the same name but different fields Fangrui Song 2020-02-06 8:33 ` Alan Modra 2020-02-06 9:19 ` Fangrui Song 2020-02-06 14:09 ` Alan Modra 2020-02-06 17:25 ` bd1976 llvm 2020-02-10 5:21 ` Alan Modra 2020-03-03 21:20 ` Empty section flags Fangrui Song 2020-04-04 14:17 ` H.J. Lu 2020-04-04 16:38 ` Fangrui Song 2020-04-04 16:45 ` H.J. Lu 2020-04-13 21:32 ` Fangrui Song [not found] ` <CAN30aBGpQecmszv-JsZwVTNrOTW0dGt4zUjas7Cx6b-B3XwjgQ@mail.gmail.com> 2020-04-04 0:43 ` 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).