[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
Mon Mar 1 08:37:27 GMT 2021
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.
More information about the Glibc-bugs
mailing list