[Bug libc/27492] New: Make static linking friendly with {ld.bfd,ld.lld} -z start-stop-gc: removing unused section '__libc_atexit'

["i at maskray dot me" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27492

            Bug ID: 27492
           Summary: Make static linking friendly with {ld.bfd,ld.lld} -z
                    start-stop-gc: removing unused section '__libc_atexit'
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: i at maskray dot me
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

#include <stdio.h>
#include <stdlib.h>

void hook() {
  puts("hello");
}
int main() {
  atexit(hook);
}

// Require -z start-stop-gc, which is available in trunk ld.lld
(https://reviews.llvm.org/D96914) and GNU ld newer than 2021-03-01
(https://sourceware.org/bugzilla/show_bug.cgi?id=27451)
% gcc -static a.c -Wl,--gc-sections -z start-stop-gc
% ./a.out
hello

This appears to work. However, if you use the approach in
https://sourceware.org/pipermail/binutils/2021-February/115561.html to compare
-z nostart-stop-gc and -z start-stop-gc output,
you should notice a difference

% diff 0 1
16a17
> /home/ray/Dev/binutils-gdb/Debug/ld/ld-new: removing unused section '__libc_atexit' in file 'usr/lib/x86_64-linux-gnu/libc.a(genops.o)'


I don't know whether the difference matters. In 2010, this difference caused
bug 11133.
A GNU ld workaround was installed.
Then in 2015-10, the "__start_xx reference from a live input section retain all
xx sections" rule was extended to all translation units.
This is unfortunate because many modern metadata section usage cannot be GCed.
(See "Metadata sections referenced by text sections" in
http://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order )


If __libc_atexit wants to be a GC root, use SHF_GNU_RETAIN;
otherwise, use an artificial relocation like R_X86_64_NONE (see
https://lwn.net/Articles/741494/)

-- 
You are receiving this mail because:
You are on the CC list for the bug.