[Bug ld/27973] ld x86: Allow direct access to protected function symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=27973 Fangrui Song changed: What|Removed |Added Target||x86_64-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27973] New: ld x86: Allow direct access to protected function symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=27973
Bug ID: 27973
Summary: ld x86: Allow direct access to protected function
symbols
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
// a.c
__attribute__((visibility("protected"))) void *foo () {
return (void *)foo;
}
// This roughly maps to:
.globl foo
.protected foo
.type foo, @function
foo:
leaqfoo(%rip), %rax
% gcc -fpic -shared -fuse-ld=bfd a.s
/usr/bin/ld.bfd: /tmp/ccWPJCLw.o: relocation R_X86_64_PC32 against protected
symbol `foo' can not be used when making a shared object
/usr/bin/ld.bfd: final link failed: bad value
collect2: error: ld returned 1 exit status
The diagnostic was probably added circa 2016/2017 to make copy relocations on
protected data symbols work with glibc.
It should not apply to function symbols.
The "copy relocations on protected data symbols" scheme has some fragile
support with GNU ld and glibc on x86 (acked by multiple glibc maintainers).
It definitely did not work before circa 2016, and should not work in the
future.
This scheme does not work with gold or LLD.
GNU ld for non-x86 architectures don't work.
I think no software will break if we drop the fragile glibc support.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/27246] ld.gold does not support DWARF5
https://sourceware.org/bugzilla/show_bug.cgi?id=27246 H.J. Lu changed: What|Removed |Added CC||dmantipov at yandex dot ru --- Comment #20 from H.J. Lu --- *** Bug 27971 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27971] gold: internal error in format_file_lineno, at dwarf_reader.cc:2278
https://sourceware.org/bugzilla/show_bug.cgi?id=27971 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 27246 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27971] New: gold: internal error in format_file_lineno, at dwarf_reader.cc:2278
https://sourceware.org/bugzilla/show_bug.cgi?id=27971 Bug ID: 27971 Summary: gold: internal error in format_file_lineno, at dwarf_reader.cc:2278 Product: binutils Version: 2.36.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: dmantipov at yandex dot ru CC: ian at airs dot com Target Milestone: --- Created attachment 13488 --> https://sourceware.org/bugzilla/attachment.cgi?id=13488=edit Toy 'project' (with Makefile, just 'make' to reproduce) Just 'make' to reproduce, '-gdwarf-5' only (no internal error if '-gdwarf-4'): $ make gcc -O0 -g3 -gdwarf-5 -c -o test.o test.c gcc -O0 -g3 -gdwarf-5 -c -o foobarbaz.o foobarbaz.c gcc -O0 -g3 -gdwarf-5 -shared -o libfoobarbaz.so foobarbaz.o -Wl,-version-script -Wl,foobarbaz.ver gcc -O0 -g3 -gdwarf-5 -o test test.o -L. -lfoobarbaz /usr/bin/ld: internal error in format_file_lineno, at dwarf_reader.cc:2278 collect2: error: ld returned 1 exit status -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26018] --dynamic-list* doesn't work before -Bsymbolic and -Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=26018
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #8 from Michael Matz ---
This might have broken usage in the wild. In libqt4 this feature is used as
follows:
g++ ... -shared -Wl,-Bsymbolic-functions -Wl,--dynamic-list,QtCore.dynlist ...
with QtCore.dynlist only containing function names:
-
{
extern "C" {
"qt_startup_hook";
"qt_addObject";
"qt_removeObject";
};
extern "C++" {
"QEventLoop::exec(QFlags)";
};
};
-
The intent is that all functions are bound locally, except for the few ones
explicitely mentioned. That worked fine with binutils 2.32, an excerpt from
the
relocations:
...
004e4bc8 047e0006 R_X86_64_GLOB_DAT 004e5900
_ZN7QString11shared_nullE + 0
...
I've singled out this one because it's important: this shared_null member _must
not_ be bound symbolically, there must be only one in the process image, and
there exist (non-PIE) binaries that contain COPY relocations on it. So
relocations to this symbol need to stay in the shared lib, i.e. it must remain
dynamic.
With binutils 2.35 _ZN7QString11shared_nullE is bound symbolically, there's
no trace of it in the relocation of libQtCore.so.4 anymore, breaking stuff
in interesting ways (e.g. some executables hang at start).
I think what this (old) libqt4 link command is doing is reasonable: it wants
default behaviour for symbol binding, then overrides this for functions (to be
bound symbolically) and then overrides _that_ for some further functions (to
again be bound as per default, i.e. late). I.e. the overall expectation that
data objects remain bound late with that command line seem sensible.
I haven't yet verified if this commit is really at fault, but it looks at least
related and I wanted to leave a trace in case I can't continue with analysis
tomorrow. If it's not this, then it's some other change since 2.32.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/26706] pad strings in .dynstr
https://sourceware.org/bugzilla/show_bug.cgi?id=26706 Ben Woodard changed: What|Removed |Added CC|mcermak at redhat dot com | -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26706] pad strings in .dynstr
https://sourceware.org/bugzilla/show_bug.cgi?id=26706 Ben Woodard changed: What|Removed |Added CC||mcermak at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
