[Bug gold/16530] New: --dynamic-list does not protect symbols from being garbage collected
https://sourceware.org/bugzilla/show_bug.cgi?id=16530
Bug ID: 16530
Summary: --dynamic-list does not protect symbols from being
garbage collected
Product: binutils
Version: 2.25 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ian at airs dot com
Reporter: eugeni.stepanov at gmail dot com
CC: ccoutant at google dot com
$ cat z.cc
extern "C" void f() {}
int main() { return 0; }
$ cat z.syms
{
f;
};
$ g++ z.cc -o z -Wl,--dynamic-list,z.syms -Wl,--gc-sections -ffunction-sections
$ objdump -T z
With Gold linker (today's trunk), f is not exported from the executable. With
BFD linker, it is exported as a local(?) symbol.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18780] New: Gold does not support long PLT on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=18780 Bug ID: 18780 Summary: Gold does not support long PLT on ARM Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: eugeni.stepanov at gmail dot com CC: ian at airs dot com Target Milestone: --- The BFD linker has a -long-plt option to generate 16-byte PLT entries that are capable of addressing GOT at arbitrary offset. Gold only knows how to emit 12-byte PLT entries which limits the linked binary to 0xFFF (256MB) offset between PLT and GOT. Linking a larger binary results in the following error (at HEAD): ld.gold: internal error in do_fill_plt_entry, at arm.cc:7799 In case the code moves later, this refers to the following lines in do_fill_plt_entry: int32_t offset = ((got_address + got_offset) - (plt_address + plt_offset + 8)); gold_assert(offset >= 0 && offset < 0x0fff); -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18859] New: Gold linker does not fully respect -no-as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=18859
Bug ID: 18859
Summary: Gold linker does not fully respect -no-as-needed
Product: binutils
Version: 2.26 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: eugeni.stepanov at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Gold and ld behave differently when a shared library is first mentioned when
-as-needed is in effect, and then again after -no-as-needed. Ld generates a
DT_NEEDED entry for such library, and gold does not.
$ cat 1.c
int main() { return 0; }
# BFD linker
$ g++ 1.c -Wl,-as-needed -lutil -Wl,-no-as-needed -lutil -fuse-ld=bfd &&
readelf -d a.out | grep NEEDED
0x0001 (NEEDED) Shared library: [libutil.so.1]
0x0001 (NEEDED) Shared library: [libstdc++.so.6]
0x0001 (NEEDED) Shared library: [libm.so.6]
0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0001 (NEEDED) Shared library: [libc.so.6]
# Gold linker
$ g++ 1.c -Wl,-as-needed -lutil -Wl,-no-as-needed -lutil -fuse-ld=gold &&
readelf -d a.out | grep NEEDED
0x0001 (NEEDED) Shared library: [libstdc++.so.6]
0x0001 (NEEDED) Shared library: [libm.so.6]
0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0001 (NEEDED) Shared library: [libc.so.6]
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18859] Gold linker does not fully respect -no-as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=18859 --- Comment #2 from Evgeniy Stepanov --- There is some context here: https://llvm.org/bugs/show_bug.cgi?id=15823 In the clang driver, we add a static library that implements wrappers for libutil functions, i.e. it exports functions with the same names and calls the real libutil functions with dlsym(RTLD_NEXT). To ensure that the executable still depends on libutil, we add -no-as-needed -lutil to the end of the link line - otherwise the linker thinks that all libutil dependencies are already satisfied by the wrapper library. The first "-as-needed -lutil" comes from the clang command line. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/18859] Gold linker does not fully respect -no-as-needed
https://sourceware.org/bugzilla/show_bug.cgi?id=18859 --- Comment #4 from Evgeniy Stepanov --- Thank you! --wrap does not work for prebuilt shared libraries, and we need to intercept at least some functions in those, too (ex. malloc). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19169] New: Gold emits incorrect R_AARCH64_ABS64
https://sourceware.org/bugzilla/show_bug.cgi?id=19169
Bug ID: 19169
Summary: Gold emits incorrect R_AARCH64_ABS64
Product: binutils
Version: 2.24
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: eugeni.stepanov at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
The following code, when placed in a non-symbolically linked shared library,
fails on Android/AArch64 when linked with gold.
int A[10] = {1, 0};
int *B = A;
extern "C" void f() {
int *C = A;
assert(B == C);
}
Let's reduce it to:
int A[10] = {1, 0};
int *B = A;
$ objdump -t 1.o
g O .data 0028 A
g O .data.rel 0008 B
$ objdump -r 1.o
RELOCATION RECORDS FOR [.data.rel]:
OFFSET TYPE VALUE
R_AARCH64_ABS64 A
$ objdump -s -j .data.rel 1.o
Contents of section .data.rel:
Link with gold.
$ objdump -T gold.so
2018 gDO .data 0028 A
2040 gDO .data 0008 B
$ objdump -R gold.so
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE
1e28 R_AARCH64_RELATIVE *ABS*+0x03e0
2040 R_AARCH64_ABS64 A
$ objdump -s -j .data gold.so
Contents of section .data:
2010 0100
2020
2030
2040 1820 . ..
The addend at 0x2040 is not zero. This makes B point to A + 0x182.
The addend should be zero.
To reproduce:
grab android-ndk-r10e from google
./build/tools/make-standalone-toolchain.sh --toolchain
aarch64-linux-android-clang3.6 --platform=android-21
--install-dir=standalone-clang-aarch64
cd standalone-clang-aarch64
cat >1.cc
int A[10] = {1, 0};
int *B = A;
^D
./bin/clang++ 1.cc -shared -fPIC -o 1.so -fuse-ld=gold
objdump -s -j .data 1.so
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19169] Gold emits incorrect R_AARCH64_ABS64
https://sourceware.org/bugzilla/show_bug.cgi?id=19169 --- Comment #1 from Evgeniy Stepanov --- Oh, > 2040 1820 This is actually 0x2018, which is the VMA of "A". So this points to A+A, which is definitely wrong. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19169] Gold emits incorrect R_AARCH64_ABS64
https://sourceware.org/bugzilla/show_bug.cgi?id=19169 --- Comment #2 from Evgeniy Stepanov --- It appears that this is a bug in the bionic linker which incorrectly loads the addend for RELA relocations from the relocated address. See https://sourceware.org/bugzilla/show_bug.cgi?id=19163 The bug is present in L and M versions of Android, so it looks like gold should zero-fill the relocated address as a workaround. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19002] .eh_frame error: "no .eh_frame_hdr table will be created" with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=19002 Evgeniy Stepanov changed: What|Removed |Added CC||eugeni.stepanov at gmail dot com Version|2.25|2.27 (HEAD) --- Comment #2 from Evgeniy Stepanov --- The same problem is present in the ToT gold. A simpler test case. The input asm contains a single .init_array constructor in its own comdat. $ cat 1.s .text .file "1.ll" .section.text.f,"axG",@progbits,f,comdat .p2align4, 0x90 .type f,@function f: # @f .cfi_startproc # BB#0: retq .Lfunc_end0: .size f, .Lfunc_end0-f .cfi_endproc .section.init_array.0,"aGw",@init_array,f,comdat .p2align3 .quad f .section".note.GNU-stack","",@progbits $ as 1.s -o 1.o $ ld.gold -r -o full.o 1.o 1.o $ ld.bfd -shared full.o -o libfull.so ld: error in full.o(.eh_frame); no .eh_frame_hdr table will be created. The resulting library has an empty (header-only) eh_frame_hdr: 12 .eh_frame_hdr 0008 06b0 06b0 06b0 2**2 If ld.gold is used instead of ld.bfd in the second link, then there is no error message, but the same end result. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19002] .eh_frame error: "no .eh_frame_hdr table will be created" with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=19002 --- Comment #4 from Evgeniy Stepanov --- Thank you, Cary! -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19002] .eh_frame error: "no .eh_frame_hdr table will be created" with gold
https://sourceware.org/bugzilla/show_bug.cgi?id=19002 --- Comment #6 from Evgeniy Stepanov --- The bfd linker warning about not being able to build .eh_frame_hdr was very useful for me. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/19887] New: --export-dynamic-symbol ignored for plugin symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=19887
Bug ID: 19887
Summary: --export-dynamic-symbol ignored for plugin symbols
Product: binutils
Version: 2.27 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: eugeni.stepanov at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
$ cat 1.c
void f() {}
int main() {}
$ clang -flto -O0 1.c -fuse-ld=gold -Wl,--export-dynamic-symbol=f
-Wl,-plugin-opt,generate-api-file
$ cat apifile.txt
f PREVAILING_DEF_IRONLY
main PREVAILING_DEF
Gold says that "f" is PREVAILING_DEF_IRONLY, i.e. has no external references. I
believe it should be PREVAILING_DEF_IRONLY_EXP due to
--export-dynamic-symbol=f.
The following patch implements the desired behaviour, though I'm not 100% sure
this is the best place for the fix.
--- a/gold/plugin.cc
+++ b/gold/plugin.cc
@@ -930,7 +930,10 @@ is_visible_from_outside(Symbol* lsym)
{
if (lsym->in_dyn())
return true;
- if (parameters->options().export_dynamic() ||
parameters->options().shared())
+ if (parameters->options().export_dynamic() ||
+ parameters->options().shared() ||
+ parameters->options().in_dynamic_list(lsym->name()) ||
+ parameters->options().is_export_dynamic_symbol(lsym->name()))
return lsym->is_externally_visible();
return false;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
