public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug middle-end/100062] New: Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat @ 2021-04-13 11:22 ibuclaw at gdcproject dot org 2021-04-13 13:45 ` [Bug middle-end/100062] " rguenth at gcc dot gnu.org ` (2 more replies) 0 siblings, 3 replies; 4+ messages in thread From: ibuclaw at gdcproject dot org @ 2021-04-13 11:22 UTC (permalink / raw) To: gcc-bugs 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". ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/100062] Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat 2021-04-13 11:22 [Bug middle-end/100062] New: Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat ibuclaw at gdcproject dot org @ 2021-04-13 13:45 ` rguenth at gcc dot gnu.org 2021-04-17 21:28 ` ibuclaw at gdcproject dot org 2021-12-11 22:57 ` [Bug d/100062] " ibuclaw at gdcproject dot org 2 siblings, 0 replies; 4+ messages in thread From: rguenth at gcc dot gnu.org @ 2021-04-13 13:45 UTC (permalink / raw) To: gcc-bugs 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? ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/100062] Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat 2021-04-13 11:22 [Bug middle-end/100062] New: Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat ibuclaw at gdcproject dot org 2021-04-13 13:45 ` [Bug middle-end/100062] " rguenth at gcc dot gnu.org @ 2021-04-17 21:28 ` ibuclaw at gdcproject dot org 2021-12-11 22:57 ` [Bug d/100062] " ibuclaw at gdcproject dot org 2 siblings, 0 replies; 4+ messages in thread From: ibuclaw at gdcproject dot org @ 2021-04-17 21:28 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug d/100062] Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat 2021-04-13 11:22 [Bug middle-end/100062] New: Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat ibuclaw at gdcproject dot org 2021-04-13 13:45 ` [Bug middle-end/100062] " rguenth at gcc dot gnu.org 2021-04-17 21:28 ` ibuclaw at gdcproject dot org @ 2021-12-11 22:57 ` ibuclaw at gdcproject dot org 2 siblings, 0 replies; 4+ messages in thread From: ibuclaw at gdcproject dot org @ 2021-12-11 22:57 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-12-11 22:57 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-13 11:22 [Bug middle-end/100062] New: Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat ibuclaw at gdcproject dot org 2021-04-13 13:45 ` [Bug middle-end/100062] " rguenth at gcc dot gnu.org 2021-04-17 21:28 ` ibuclaw at gdcproject dot org 2021-12-11 22:57 ` [Bug d/100062] " ibuclaw at gdcproject dot org
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).