.section directives with the same name but different fields

.section directives with the same name but different fields

[Fangrui Song]

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

Re: .section directives with the same name but different fields

[Alan Modra]

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

Re: .section directives with the same name but different fields

[Fangrui Song]

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

Re: .section directives with the same name but different fields

[Alan Modra]

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

Re: .section directives with the same name but different fields

[bd1976 llvm]

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.

Re: .section directives with the same name but different fields

[Alan Modra]

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

Empty section flags

[Fangrui Song]

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.

Re: Empty section flags

[H.J. Lu]

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.

Re: Empty section flags

[Fangrui Song]

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

Re: Empty section flags

[H.J. Lu]

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.

Re: Empty section flags

[Fangrui Song]

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

Re: Empty section flags

[Fangrui Song]

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? :)