[Bug c++/108761] New: Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object

[Bug c++/108761] New: Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761

            Bug ID: 108761
           Summary: Add option to produce a unique section for non-COMDAT
                    __attribute__((section("foo"))) object
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: i at maskray dot me
  Target Milestone: ---

% cat a.cc
__attribute__((section("foo"))) void f() {}
__attribute__((section("foo"))) void g() {}
% g++ -c -ffunction-sections a.cc
% readelf -WS a.o | grep foo
  [ 4] foo               PROGBITS        0000000000000000 000040 00000e 00  AX 
0   0  1

There is one section named `foo`, with f and g in it (they do not use COMDAT).
In ld --gc-sections, f and g are retained or discarded as a unit.

If we place f and g in two `foo` sections, --gc-sections can discard them
separately.
(We need assembler syntax `.section foo,"ax",@progbits,unique,1` which requires
binutils>=2.35.)


https://reviews.llvm.org/D143745 proposes to add such a feature with an option
name like `-ffunction-sections[=(default,all)]`.
I feel that the option argument is non-intuitive but do not come up with a
better name right now.
I raise this feature request to seek feedback from GCC :)

[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think an option would be the wrong appoarch because many of the times, you
are marking a variable inside a section exactly because you want it to be part
of an "array".

I think rather section should have a secondary argument which mark as needing
to append the function name on it ...

[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> I think rather section should have a secondary argument which mark as
> needing to append the function name on it ...

s/function name/decl assembly name/

[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object

[i at maskray dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761

--- Comment #3 from Fangrui Song <i at maskray dot me> ---
New syntax setting the flags will be useful. Also, currently there is no way to
customize the section type.

[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object

[paul_robinson at playstation dot sony.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761

Paul Robinson <paul_robinson at playstation dot sony.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paul_robinson at playstation dot s
                   |                            |ony.com

--- Comment #4 from Paul Robinson <paul_robinson at playstation dot sony.com> ---
(In reply to Andrew Pinski from comment #1)
> I think an option would be the wrong appoarch because many of the times, you
> are marking a variable inside a section exactly because you want it to be
> part of an "array".

I think distinct options for -ffunction-sections and -fdata-sections
would be the answer to that.  I mean, we _already_ have separation
options, so handling code and data independently makes sense.

> I think rather section should have a secondary argument which mark as
> needing to append the function name on it ...

I believe the linker will not take an input with sections "foo.f" and
"foo.g" and concatenate them into a single "foo" section in the linked object.
That special behavior works only for standard sections like .text AFAIK.
The Clang change proposes using section groups instead, so the final
section has the name the user specified.

I don't know whether this would work for non-ELF object formats.
I suspect COFF would be okay, as it has no-deduplicate COMDAT.

[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object

[paul_robinson at playstation dot sony.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761

--- Comment #5 from Paul Robinson <paul_robinson at playstation dot sony.com> ---
Modifying the syntax of the attribute won't help users who are importing
code from a third party, but still want to do dead-stripping/deduplication.

[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Paul Robinson from comment #5)
> Modifying the syntax of the attribute won't help users who are importing
> code from a third party, but still want to do dead-stripping/deduplication.

And it might break code from third party with that option, that was my point.

[Bug c++/108761] Add option to produce a unique section for non-COMDAT __attribute__((section("foo"))) object

[paul_robinson at playstation dot sony.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108761

--- Comment #7 from Paul Robinson <paul_robinson at playstation dot sony.com> ---
Okay. I'm persuaded this is not a great idea, and I'll solve the customer's
problem another way.