* .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
[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
* 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
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).