[Bug middle-end/100062] New: Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat

[Bug middle-end/100062] New: Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat

[ibuclaw at gdcproject dot org]

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

            Bug ID: 100062
           Summary: Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on
                    comdat
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

In the D front-end, each DSO with D code is (de)registered against the druntime
library, this is done with two functions that are approximately equivalent to:

___attribute___((visibility ("hidden"), weak, constructor)) void d.dso_ctor();
___attribute___((visibility ("hidden"), weak, destructor)) void d.dso_dtor();

This could be reduced to a single function - without the need for a static
guard to insure against multiple calls - if constructors/destructors were put
in comdat.  In the examples below, I'll name it d.register_dso:

##
## ELF
##

# GCC emits this as (default_elf_init_array_asm_out_constructor):

  .section .init_array,"aw"
  .align 8
  .quad d.register_dso

# Would like the ability to instead do:

  .section .init_array,"aGw",@init_array,register_dso,comdat
  .align 8
  .quad d.register_dso

##
## Macho
##

# GCC emits this as(darwin_file_end/finalize_ctors)

  .mod_init_func
  .align 3
  .quad   _d.register_dso

# Would like the ability to instead do:

  .section __DATA,__mod_init_func,mod_init_funcs
  .globl _d.dso_ctor
  .weak_definition _d.dso_ctor
  .align 3
_d.dso_ctor:
  .quad _d.register_dso


The above is already be achievable on darwin by ignoring
DECL_STATIC_CONSTRUCTOR, and using get_section() directly.

However on ELF, the only types that GCC emits (default_elf_asm_named_section)
are either "@nobits" or "@progbits".  It is not possible to request either
"@init_array" or "@fini_array".

[Bug middle-end/100062] Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Since you say this happens on a DSO level why is this not achieved via some
additional object at link-time (like crt*.o)?  It sounds like you place
the CDTOR in each object file instead and want to merge them in the linker
via comdat?

[Bug middle-end/100062] Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Richard Biener from comment #1)
> Since you say this happens on a DSO level why is this not achieved via some
> additional object at link-time (like crt*.o)?  It sounds like you place
> the CDTOR in each object file instead and want to merge them in the linker
> via comdat?

Quite possibly, though I'd have to see if what is generated is readily
representable in C (or D) code.

That is correct, currently the CDTORs are put in each object file.  My initial
assumption is that it would be trivial to adapt get_section.

[Bug d/100062] Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat

[ibuclaw at gdcproject dot org]

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

Iain Buclaw <ibuclaw at gdcproject dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |d

--- Comment #3 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
Switching the component over to D and will switch the implementation over to a
drtstuff object file that does what we want in code, rather than magically in
the D front-end code generator.