Re: RFC Adding a section group flag of 0

[H.J. Lu]

On Wed, Jan 9, 2019 at 6:53 AM Nick Clifton <ni...@redhat.com> wrote:
>
> Hi Guys,
>
> Currently the ELF standard for section groups requires that the first word
> of data in the group section be a flag, with only certain values recognised:
>
> The following flags are currently defined:
> Figure 4-13: Section Group Flags
>
> Name Value
> GRP_COMDAT 0x1
> GRP_MASKOS 0x0ff00000
> GRP_MASKPROC 0xf0000000
>
> [...]
>
> I would like to propose adding a new value to this list. A value of 0.
> This value would indicate that the section group has no special processing
> semantics, and that the contents of the group, unless discarded via garbage
> collection, should be linked as normal.
>
> This matches the current behaviour of the bfd and gold linkers, and it would
> also help to resolve a problem for the lld linker:
>
> https://reviews.llvm.org/D56437
>
> This is not a theoretical problem, as binaries containing section groups with
> a flag value of zero already exist:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1658942
>
> The maintainers of lld have stated, quite reasonably, that they do not want to
> add support for an unofficial flag value. Hence I would like to make the value
> official.
>
> What do people think ?
>

I CCed gABI group where this issue should be discussed.

--
H.J.

[Florian Weimer]

* Nick Clifton:

> Hi Guys,
>
> Currently the ELF standard for section groups requires that the first word
> of data in the group section be a flag, with only certain values recognised:
>
> The following flags are currently defined:
> Figure 4-13: Section Group Flags
>
> Name Value
> GRP_COMDAT 0x1
> GRP_MASKOS 0x0ff00000
> GRP_MASKPROC 0xf0000000
>
> [...]
>
> I would like to propose adding a new value to this list. A value of 0.
> This value would indicate that the section group has no special processing
> semantics, and that the contents of the group, unless discarded via garbage
> collection, should be linked as normal.
>
> This matches the current behaviour of the bfd and gold linkers, and it would
> also help to resolve a problem for the lld linker:
>
> https://reviews.llvm.org/D56437
>
> This is not a theoretical problem, as binaries containing section groups with
> a flag value of zero already exist:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1658942
>
> The maintainers of lld have stated, quite reasonably, that they do not want to
> add support for an unofficial flag value. Hence I would like to make the value
> official.

According to my reading of the specification, the behavior of flag 0 is
already specified. Setting GRP_COMDAT merely enables deduplication of
the section group based on its name. With flag 0, the name is not used
and no deduplication happens.

Thanks,
Florian

[Peter Smith]

This was my first interpretation as well. I had assumed that the flags
specified additional properties over the default. As a possible
alternative to adding 0 as a value, maybe a clarifying sentence in the
paragraph above.

Peter

[James Y Knight]

I think this is just a misunderstanding and no spec change is required -- the spec isn't documenting a list of allowed values, but rather bits which may individually be set, or not set. If 0x1 is set, then the comdat semantics are added to the generic section-group semantics spelled out in the remainder of the text.

--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To post to this group, send email to gener...@googlegroups.com.
Visit this group at https://groups.google.com/group/generic-abi.
For more options, visit https://groups.google.com/d/optout.

[Ali Bahrami]

On 01/ 9/19 08:00 AM, Florian Weimer wrote:
> According to my reading of the specification, the behavior of flag 0 is
> already specified. Setting GRP_COMDAT merely enables deduplication of
> the section group based on its name. With flag 0, the name is not used
> and no deduplication happens.

That's how I read it as well. The flag element provides
the ability to set options, GRP_COMDAT being the only one
currently defined. It's not necessary to say that you don't have
to set any flags, or that the result of not setting any
flags would be 0,

One could argue that an SHT_GROUP without GRP_COMDAT set is
pointless, but I believe the spec allows it, and looking at
our Solaris implementation, we accept it. The result is to
validate the group, but then, nothing more is done with it.
Nick, I am curious why gcc produces these GROUP sections. Not
challenging their right to do so, but wondering what benefit
they derive from it.

The LLVM folks caution on this is appreciated, but I think they
should make the change, and that the ABI doesn't need to be clarified..

- Ali

[Jim Dehnert]

Florian is right.  See the Solaris reference to the Group Section description in the bug that was referenced above: https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/chapter7-26/index.html

The section description describes what to do with sections in groups (keep or discard them as a unit), and how the GRP_COMDAT flag affects them (they may be duplicated based on name, and the linker should keep one and discard the rest).  There's no need for a description of what to do if GRP_COMDAT is not set -- it's already there in the Group Section description.

It's better to think of the flags as masks, and the value is the masked bit.  Zero is not one of the flags, a zero flag word is a combination of false values for all defined flags.  Defining a zero "flag" will cause trouble as soon as another flag is defined -- (sh_flags & GRP_COMDAT == 0) is not the same thing as (sh_flags == GRP_ZERO).

--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To post to this group, send email to gener...@googlegroups.com.
Visit this group at https://groups.google.com/group/generic-abi.
For more options, visit https://groups.google.com/d/optout.

--

--
             Jim Dehnert
             deh...@gmail.com
         

[James Henderson]

I'm in the same camp as Florian and Peter. The first word is a _flag_ word. The gABI doesn't define a section header flag for value 0, for example, so why should it for groups? Flags are typically additive in nature, so a zero value would be meaningless. I agree that a clarifying sentence would probably be beneficial though. Perhaps the sentence "The following flags are currently defined:" could be prefixed with something like the following sentence: "If specified, flags extend the group section behaviour as described below..."

[ben.du...@sony.com]

On Wednesday, 9 January 2019 15:00:44 UTC, Florian Weimer wrote:

* Nick Clifton:

>   I would like to propose adding a new value to this list.  A value of 0.
>   This value would indicate that the section group has no special processing
>   semantics, and that the contents of the group, unless discarded via garbage
>   collection, should be linked as normal.
>
>   This matches the current behaviour of the bfd and gold linkers, and it would
>   also help to resolve a problem for the lld linker:

I *strongly* disagree with this proposal. ELF groups and --gc-sections should be orthogonal features.

This has been brought up on this list and clarified before, see: https://groups.google.com/d/msg/generic-abi/_CbBM6T6WeM/cSELn86gAQAJ

Quoting from that thread:

The ELF spec (aka gABI) does not discuss GC at all. Garbage collection 
is offered by ld and gold as an optional feature beyond what is 
specified by the gABI. It has nothing to do with section groups.

Keeping groups and --gc-sections orthogonal is important:

- It keeps the implementation of group support simple and efficient in ELF linkers.

- It allows the removal of individual sections within a group by --gc-sections (and other operations).

The GABI contains the following note:

This requirement is not intended to imply that special case behavior like removing debugging information requires removing the sections to which that information refers, even if they are part of the same group.

i.e. groups are orthogonal to other other per-section operations like --gc-sections. 

 

>   This is not a theoretical problem, as binaries containing section groups with
>   a flag value of zero already exist:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1658942
>

According to Peter's research these are coming from the following tool: https://www.mankier.com/1/annobin

> From the man page: https://www.mankier.com/1/annobin

"attach""no-attach"
When gcc compiles code with the -ffunction-sections option active it will place each function into its own section.  When the annobin attach option is active the plugin will attempt to attach the function section to a group containing the notes and relocations for the function.  In that way, if the linker decides to discard the function, it will also know that it should discard the notes and relocations as well.

This tool is not emitting correct ELF. It should be using SHF_LINK_ORDER rather than groups.