Initialization in C++ is Seriously Bonkers

Re:Initialization in C++ is Seriously Bonkers by waynecochran on Saturday January 05, 2019 @07:00PM (#18835259)

./libgcc/config/nds32/crtzero.S

    .L_bss_init:
        ! clear BSS, this process can be 4 time faster if data is 4 byte aligned
        ! if so, use swi.p instead of sbi.p
        ! the related stuff are defined in linker script
        la  $r0, _edata     ! get the starting addr of bss
        la  $r2, _end       ! get ending addr of bss
        beq $r0, $r2, .L_call_main  ! if no bss just do nothing
        movi    $r1, 0          ! should be cleared to 0
    .L_clear_bss:
        sbi.p   $r1, [$r0], 1       ! Set 0 to bss
        bne $r0, $r2, .L_clear_bss  ! Still bytes left to set

[ Parent | on HN ]

Re:Initialization in C++ is Seriously Bonkers by ajross on Saturday January 05, 2019 @08:08PM (#18835602)

How does finding some uncompiled sample code someone added to gcc for an architecture no one has heard of refute the point that glibc on Linux implements bss with an anonymous mmap?

[ Parent | on HN ]

Re:Initialization in C++ is Seriously Bonkers by waynecochran on Sunday January 06, 2019 @12:26AM (#18836720)

Not meant to refute, just sample code on the C runtime zeroing the bss section. You'll find this for a variety of systems, this was just one of them...

[ Parent | on HN ]

Re:Initialization in C++ is Seriously Bonkers by monocasa on Saturday January 05, 2019 @10:59PM (#18836487)

Rather than pointing to Linux over and over, let's look at Win95. It kind of comes from a 'fuck local security' standpoint (everything mmaped is in one global space mapped into all processes), and still clears bss because that's what the spec expects, and like a lot of embedded systems is fully spec compliant.

[ Parent | on HN ]