differences between GCC and LLVM with __attribute__((constructor)) __attribute__((destructor))

[LukeSTM]

demo:

void __attribute__((constructor)) kkk2()
{
        __asm__ volatile ("":::);
}

void __attribute__ ((destructor)) foo()
{
        __asm__ volatile ("":::);
}

https://godbolt.org/z/7shvxT3hY

There are differences in the behavior of __attribute__((constructor)) __attribute__((destructor)) between GCC and LLVM. GCC places functions with the __attribute__((constructor)) attribute in the .text.startup section, and places functions with the __attribute__((destructor)) attribute in the .text.exit section，but LLVM does not. Why is this the case?

[LukeSTM]

gcc objdump
kkk2 in .text.startup
foo in .text.exit

    .file   "demo.c"
    .text
    .section    .text.startup,"ax",@progbits
    .p2align 4,,15
    .globl  kkk2
    .type   kkk2, @function
kkk2:
.LFB0:
    .cfi_startproc
    ret
    .cfi_endproc
.LFE0:
    .size   kkk2, .-kkk2
    .section    .ctors,"aw",@progbits
    .align 8
    .quad   kkk2
    .section    .text.exit,"ax",@progbits
    .p2align 4,,15
    .globl  foo
    .type   foo, @function
foo:
.LFB1:
    .cfi_startproc
    ret
    .cfi_endproc
.LFE1:
    .size   foo, .-foo
    .section    .dtors,"aw",@progbits
    .align 8
    .quad   foo

llvm objdump
kkk2 in .text
foo in .text

    .text
    .file   "demo.c"
    .globl  kkk2                            # -- Begin function kkk2
    .p2align    4, 0x90
    .type   kkk2,@function
kkk2:                                   # @kkk2
    .cfi_startproc
# %bb.0:
    #APP
    #NO_APP
    retq
.Lfunc_end0:
    .size   kkk2, .Lfunc_end0-kkk2
    .cfi_endproc
                                        # -- End function
    .globl  foo                             # -- Begin function foo
    .p2align    4, 0x90
    .type   foo,@function
foo:                                    # @foo
    .cfi_startproc
# %bb.0:
    #APP
    #NO_APP
    retq
.Lfunc_end1:
    .size   foo, .Lfunc_end1-foo
    .cfi_endproc
                                        # -- End function
    .section    .init_array,"aw",@init_array
    .p2align    3
    .quad   kkk2
    .section    .fini_array,"aw",@fini_array
    .p2align    3
    .quad   foo

[LukeSTM]

CC @MaskRay

[LukeSTM]

If many functions are added with attribute((constructor)), they will be more compact in the final binary, and memory usage may be lower.

[pinskia]

Note GCC starting using .text.startup/.text.exit in GCC 4.6.0. Even on Darwin puts it in .section __TEXT,__text_startup,regular,pure_instructions .

This was done to put together code that is only used during startup/exit together for less page in effect on other code. And better icache usage too. It is also used not for the constructor/destuctor attributes but also for global C++ constructors/deconstructor functions too.

[LukeSTM]

I think this is useful for LLVM.

[LukeSTM]

llvm x86 readelf dump， .rodata..L__const.do_some_test.tmp_str not be removed
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 5] .rodata..L__const.do_some_test.tmp_str PROGBITS 0000000000000000 000090 000014 00 A 0 0 16

but gcc x86 readelf dump，not keep .rodata..L__const.do_some_test.tmp_str in section

[MaskRay]

This is a wontchange to me.

GCC seems to place [[gnu::constructor]] in .text.startup) and [[gnu::destructor]] in .text.exit), and -ffunction-sections could change the section names.
I believe this is largely a cosmetic change with little noticeable impact on modern use cases.
I wouldn’t recommend adding complexity to clangCodeGen just to implement this behavior (whether section is already specified; whether -ffunction-sections)

For those looking to minimize page faults during program startup, one option is to use ld.lld --bp-startup-sort=function --irpgo-profile=<file> paired with a temporal profile.

Clang does place C++ dynamic initializations in .text.startup (getStaticInitSectionSpecifier()).

[dongjianqiang2]

This is a wontchange to me.

GCC seems to place [[gnu::constructor]] in .text.startup) and [[gnu::destructor]] in .text.exit), and -ffunction-sections could change the section names. I believe this is largely a cosmetic change with little noticeable impact on modern use cases. I wouldn’t recommend adding complexity to clangCodeGen just to implement this behavior (whether section is already specified; whether -ffunction-sections)

For those looking to minimize page faults during program startup, one option is to use ld.lld --bp-startup-sort=function --irpgo-profile=<file> paired with a temporal profile.

Clang does place C++ dynamic initializations in .text.startup (getStaticInitSectionSpecifier()).

Hi，the root cause of this issue originates from observed memory inefficiency in systems utilizing C code containing multiple functions annotated with the constructor attribute. Under GCC's default compilation strategy, such constructor functions are consolidated into a contiguous memory section. This enables the operating system to load and execute them as a single unit during initialization, after which the allocated memory can be safely reclaimed, effectively eliminating subsequent page fault risks. In contrast, Clang's current implementation distributes these constructor-attributed functions throughout the code segment. This fragmentation results in persistent memory retention for these functions, creating unnecessary memory pressure and increasing the likelihood of page faults during runtime execution.