[Bug binutils/17415] New: Overflow in relocation (R_AARCH64_TLSLE_ADD_TPREL_HI12) silently ignored
https://sourceware.org/bugzilla/show_bug.cgi?id=17415 Bug ID: 17415 Summary: Overflow in relocation (R_AARCH64_TLSLE_ADD_TPREL_HI12) silently ignored Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: shenhan at google dot com Created attachment 7795 --> https://sourceware.org/bugzilla/attachment.cgi?id=7795&action=edit test case Hi while developing gold for aarch64, we found a case (attached) that overflows relocation R_AARCH64_TLSLE_ADD_TPREL_HI12, because the offset from TP (thread pointer) is too large (bigger than 2^24). Instead of generating an error, the bfd aarch64 linker silently truncates the higher bits of offset, leading to a run time error. To reproduce, just compile - gcc -O0 case.c ./a.out The exit value is 7, but the correct value should be 0. The relocations to compute tp-offset of "i" is at 400600 and 400604, which is apparently not "10". 4005fc: d53bd040mrs x0, tpidr_el0 400600: 9140add x0, x0, #0x0, lsl #12 400604: 91004000add x0, x0, #0x10 400608: b940ldr w0, [x0] 40060c: 910043ffadd sp, sp, #0x10 400610: d65f03c0ret This was observed on trunk as well as 2.24. -- 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/18048] New: None-top-level INCLUDE not properly supported
https://sourceware.org/bugzilla/show_bug.cgi?id=18048
Bug ID: 18048
Summary: None-top-level INCLUDE not properly supported
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at google dot com
Reporter: shenhan at google dot com
CC: ian at airs dot com
We observed this problem building chromeos , I have a simplified case below -
file: test.ld
SECTIONS
{
INCLUDE "test-inc.ld"
}
file: test-inc.ld
.bss . : {
. = ALIGN(8);
}
When specifying test.ld as linker script, gold errors -
hdd2/gold64/build/gold/ld-new: error: test-inc.ld:1:6: syntax error, unexpected
STRING
hdd2/gold64/build/gold/ld-new: internal error in place_orphan, at
../../binutils-working/gold/script-sections.cc:3447
Replacing the INCLUDE statement with content from test-inc.ld makes gold happy.
--
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/18048] None-top-level INCLUDE not properly supported
https://sourceware.org/bugzilla/show_bug.cgi?id=18048 --- Comment #1 from Han Shen --- By investigating, in script.cc, "script_include_directive" function always assumes "INCLUDE" is top-most level. I'm working on a patch to expand each "INCLUDE" to reconstruct the script text and re-do the parsing. -- 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/18048] None-top-level INCLUDE not properly supported
https://sourceware.org/bugzilla/show_bug.cgi?id=18048 Han Shen changed: What|Removed |Added Assignee|ccoutant at google dot com |shenhan at google dot com -- 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/18048] None-top-level INCLUDE not properly supported
https://sourceware.org/bugzilla/show_bug.cgi?id=18048 --- Comment #4 from Han Shen --- Thanks. -- 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/18365] GOLD: AArch64: produces broken dynamic executable
https://sourceware.org/bugzilla/show_bug.cgi?id=18365 --- Comment #2 from Han Shen --- Hi Cary, sure. Han On Fri, May 1, 2015 at 11:32 AM, ccoutant at gmail dot com < sourceware-bugzi...@sourceware.org> wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=18365 > > Cary Coutant changed: > >What|Removed |Added > > > Status|NEW |ASSIGNED >Assignee|ccoutant at gmail dot com |shenhan at google > dot com > > --- Comment #1 from Cary Coutant --- > Did this only recently start failing? > > Han, can you take a look, please? > > -- > You are receiving this mail because: > You are the assignee for the bug. > -- 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/18365] GOLD: AArch64: produces broken dynamic executable
https://sourceware.org/bugzilla/show_bug.cgi?id=18365
--- Comment #3 from Han Shen ---
Hi Nick, I was not able to run your script - the 'libc.so' in the archive is
not a binary but a linker script pointing to files under your home -
"/home/nickc/work/builds/binutils/branches/2.25/aarch64-elf-gold/tests/libc.so.6
/home/nickc/work/builds/binutils/branches/2.25/aarch64-elf-gold/tests/libc_nonshared.a
AS_NEEDED (
/home/nickc/work/builds/binutils/branches/2.25/aarch64-elf-gold/tests/ld-linux-aarch64.so.1"
However I was able to dynamic gold-link conftest.o on an aarch64 box with the
following similar command line, and resulted in a runnable binary which exited
with 0.
shenhan@k:~/gold-bug$ cat shenhan.dynamic
GOLD=~/gold-aarch64/build/gold/ld-new
${GOLD} \
--build-id \
--no-add-needed \
--eh-frame-hdr \
--hash-style=gnu \
-dynamic-linker /lib/ld-linux-aarch64.so.1 \
-X \
-EL \
-maarch64linux \
-fuse-ld=gold \
-o conftest.dynamic \
/usr/lib/gcc/aarch64-linux-gnu/4.8/../../../aarch64-linux-gnu/crt1.o \
/usr/lib/gcc/aarch64-linux-gnu/4.8/../../../aarch64-linux-gnu/crti.o \
/usr/lib/gcc/aarch64-linux-gnu/4.8/crtbegin.o \
conftest.o \
-L/usr/lib/gcc/aarch64-linux-gnu/4.8 \
-L/usr/lib/gcc/aarch64-linux-gnu/4.8/../../../aarch64-linux-gnu \
-L/usr/lib/gcc/aarch64-linux-gnu/4.8/../../../../lib
-L/lib/aarch64-linux-gnu \
-L/lib/../lib -L/usr/lib/aarch64-linux-gnu \
-L/usr/lib/../lib \
-L/usr/lib/gcc/aarch64-linux-gnu/4.8/../../.. \
-lgcc \
--as-needed -lgcc_s --no-as-needed \
-lc \
-lgcc \
--as-needed -lgcc_s --no-as-needed \
/usr/lib/gcc/aarch64-linux-gnu/4.8/crtend.o \
/usr/lib/gcc/aarch64-linux-gnu/4.8/../../../aarch64-linux-gnu/crtn.o
shenhan@k:~/gold-bug$ ./shenhan.dynamic
shenhan@k:~/gold-bug$ ./conftest.dynamic
shenhan@k:~/gold-bug$ echo $?
0
shenhan@k:~/gold-bug$
--
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/18365] GOLD: AArch64: produces broken dynamic executable
https://sourceware.org/bugzilla/show_bug.cgi?id=18365 --- Comment #5 from Han Shen --- (In reply to Nick Clifton from comment #4) > Hi Han, > > Thank you for taking a look at this problem. > > > I was not able to run your script - the 'libc.so' in the archive is > > not a binary but a linker script pointing to files under your home - > > Doh! Sorry about that. I assume that you updated the file in the obvious > way ? Hi Nick, no problem. Yup, I tailored the script to my env. > > > However I was able to dynamic gold-link conftest.o on an aarch64 box with > > the following similar command line, and resulted in a runnable binary which > > exited with 0. > > Darn. > > Were you able to run the conftest.dynamic executable included in the tarball > on your system ? If so then it must be a bug on the machine I am using. Yup, both conftest.dynamic and conftest.static from the tarball run correctly on my system. > > Please could you upload a copy of the working conftest.dynamic binary so > that I can compare it to mine, and see if it runs on my machine. Attached. > > Cheers > Nick -- 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/18365] GOLD: AArch64: produces broken dynamic executable
https://sourceware.org/bugzilla/show_bug.cgi?id=18365
Han Shen changed:
What|Removed |Added
CC||shenhan at google dot com
--- Comment #6 from Han Shen ---
Created attachment 8302
--> https://sourceware.org/bugzilla/attachment.cgi?id=8302&action=edit
conftest.dynamic built in shenhan's environment
This is the binary built on my environment by command -
shenhan@k:~/gold-bug$ cat shenhan.dynamic
GOLD=~/gold-aarch64/build/gold/ld-new
${GOLD} \
--build-id \
--no-add-needed \
--eh-frame-hdr \
--hash-style=gnu \
-dynamic-linker /lib/ld-linux-aarch64.so.1 \
-X \
-EL \
-maarch64linux \
-fuse-ld=gold \
-o conftest.dynamic \
/usr/lib/gcc/aarch64-linux-gnu/4.8/../../../aarch64-linux-gnu/crt1.o \
/usr/lib/gcc/aarch64-linux-gnu/4.8/../../../aarch64-linux-gnu/crti.o \
/usr/lib/gcc/aarch64-linux-gnu/4.8/crtbegin.o \
conftest.o \
-L/usr/lib/gcc/aarch64-linux-gnu/4.8 \
-L/usr/lib/gcc/aarch64-linux-gnu/4.8/../../../aarch64-linux-gnu \
-L/usr/lib/gcc/aarch64-linux-gnu/4.8/../../../../lib
-L/lib/aarch64-linux-gnu \
-L/lib/../lib -L/usr/lib/aarch64-linux-gnu \
-L/usr/lib/../lib \
-L/usr/lib/gcc/aarch64-linux-gnu/4.8/../../.. \
-lgcc \
--as-needed -lgcc_s --no-as-needed \
-lc \
-lgcc \
--as-needed -lgcc_s --no-as-needed \
/usr/lib/gcc/aarch64-linux-gnu/4.8/crtend.o \
/usr/lib/gcc/aarch64-linux-gnu/4.8/../../../aarch64-linux-gnu/crtn.o
--
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/18365] GOLD: AArch64: produces broken dynamic executable
https://sourceware.org/bugzilla/show_bug.cgi?id=18365 Han Shen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #8 from Han Shen --- (In reply to Nick Clifton from comment #7) > Hi Han, > > > This is the binary built on my environment by command - > > Thanks. That binary fails to run on our machine, so it must be a problem > with our execution environment. (The machine is one of the Fedora Mustang > boards, running F21). I guess that you can consider this bug report as > closed, since it is not reproducible, but before you do that, please could > you tell me about your execution environment ? > > Cheers > Nick Hi, Nick, mine is a customized-built Ubuntu on a no-name machine (which means I should not reveal detail about it, sorry), the kernel version is 3.13. I'll close the bug. Thanks, Han -- 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/18348] Workaround ARM Cortex-A53 Errata 835769 & 843419
https://sourceware.org/bugzilla/show_bug.cgi?id=18348 --- Comment #1 from Han Shen --- Work in progress. -- 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/19163] arm64: zero out *reloc for bug compatibility with android linker
https://sourceware.org/bugzilla/show_bug.cgi?id=19163 --- Comment #3 from Han Shen --- Hi Cary, "*reloc" in this context refers to the dynamic relocation spot which shall be filled by android linker during binary loadup. Gold pre-fills "symbol value" to this spot, while bfd zeros it out. Actually the value at this spot is always overwritten and should never be read by dynamic linker (dynamic linker only needs information from '.rela.dyn'), unfortunately, android bionic dynamic linker *wrongly* reads that value, thus corrupted the gold-linked aarch64 image. The bug in android bionic dynamic linker has been fixed. But Dimitry suggests we keep the same behavior as bfd. I'll send out a patch tomorrow. Thanks, Han -- 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/19353] ld-new: internal error in relocate_tls, at ../../binutils/gold/aarch64.cc:7418
https://sourceware.org/bugzilla/show_bug.cgi?id=19353 Han Shen changed: What|Removed |Added CC||shenhan at google dot com --- Comment #4 from Han Shen --- Hi, Kristof, I was able to reproduce case 2 (but not 1). In gold, tls_segment is never created in layout.cc, so comes the assertion. In call_once.o, there is the tls symbol _ZSt15__once_callable, however there is no sections that has bit elfcpp::SHF_TLS turned on, and tls_segment is only created if there is at least one sectoin with SHF_TLS bit. So, Cary, shall we create the tls_segment whenever the Scanner encounters a tls 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/19472] [aarch64] Large shared objects need pc-relative stubs or relocations for absolute stubs
https://sourceware.org/bugzilla/show_bug.cgi?id=19472 Han Shen changed: What|Removed |Added CC||shenhan at google dot com Assignee|ccoutant at gmail dot com |shenhan at google dot com -- 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/19042] unsupported reloc 311/312
https://sourceware.org/bugzilla/show_bug.cgi?id=19042 Han Shen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Han Shen --- Fixed in commit 4d2f5d582. -- 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/19472] [aarch64] Large shared objects need pc-relative stubs or relocations for absolute stubs
https://sourceware.org/bugzilla/show_bug.cgi?id=19472 Han Shen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Han Shen --- Fixed in 9a472eda40ba686e45bf4922455518ffa3c887e1 -- 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/19891] arm: The order of IFUNC (R_ARM_IRELATIVE and R_ARM_JUMP_SLOT) relocations is incorrect
https://sourceware.org/bugzilla/show_bug.cgi?id=19891 Han Shen changed: What|Removed |Added Status|NEW |ASSIGNED CC||shenhan at google dot com --- Comment #1 from Han Shen --- Hi Dimitry, would you mind provide the commands / sources to reproduce this bug? I'll take a look at it. Thanks. -- 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/19891] arm: The order of IFUNC (R_ARM_IRELATIVE and R_ARM_JUMP_SLOT) relocations is incorrect
https://sourceware.org/bugzilla/show_bug.cgi?id=19891 Han Shen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Han Shen --- Discussed with reporter. This is not caused by the order of R_ARM_IRELATIVE. I'll mark this as WONTFIX. Thanks, Han -- 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/20529] New: Gold [powerpc] - relaxing loop never ends
https://sourceware.org/bugzilla/show_bug.cgi?id=20529 Bug ID: 20529 Summary: Gold [powerpc] - relaxing loop never ends Product: binutils Version: 2.28 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: shenhan at google dot com CC: ian at airs dot com Target Milestone: --- Here is one particular case that causes gold PPC linker trapped in a endless relaxing loop. (I do not provide a reproducible case because the objects involved are proprietary). Here is the case - -- || | 0x1b9446f0 | || <- stub_table | ... | || || || || | 0x1c71e3d0 |- ||| ||| ||| ||| jump delta = 0x200 ||| (>= max_branch_offset, which is 0x200) ||| ||| ||| | 0x1e71e3d0 | <--| |--- | || || So a long branch stub is added, which is 16-byte, and this pushes the section forward, thus get to the following: -- || | 0x1b9446f0 | || <- stub_table | a new stub | | ... | || || || || | 0x1c71e3e0 |- ||| ||| ||| ||| jump delta < 0x200 |||no stub needed ||| ||| ||| | 0x1e71e3d0 | <--| (the jump target is *NOT* pushed forward? why?) |--- | || || Now for this particular branch_info, we do not add a branch stub. So stub table shrinks by 16 bytes, and we get back to the first graph. Thus causes the indefinite loop. The solution is to only allow growth of stub tables after a few relax iterations. -- 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/20765] [2.27 Regression] gold internal error in fix_errata on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=20765 Han Shen changed: What|Removed |Added CC||shenhan at google dot com --- Comment #1 from Han Shen --- The erratum insn address recorded in Erratum_stub is not updated after relaxation passes, which move input sections forward / backward (thus changes the erratum insn address). I've had a preliminary patch, but that leads to relocation overflow errors. I'll continue investigation. -- 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/21215] New: Gold linker segfaults linking symbols with different versions.
https://sourceware.org/bugzilla/show_bug.cgi?id=21215
Bug ID: 21215
Summary: Gold linker segfaults linking symbols with different
versions.
Product: binutils
Version: 2.29 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: shenhan at google dot com
CC: ian at airs dot com
Target Milestone: ---
Gold linker segfaults linking symbols with different versions.
The scenarios is explained below:
We have a symbol "_ZNKSs11_M_disjunctEPKc", defined in 3 different places:
a) - "_ZNKSs11_M_disjunctEPKc" in libstdc++.a(string-inst.pic.o)
b) - "_ZNKSs11_M_disjunctEPKc@GLIBCXX_3.4" in compatibility.pic.o
c) - "_ZNKSs11_M_disjunctEPKc@@GLIBCXX_3.4.5" in compatibility.pic.o
And we link with a version script file -
GLIBCXX_3.4 {
global:
_ZNKSs11_M_disjunctEPKc;
};
The problem we have is
1) - linker reads a), gets version "3.4" from version script file, thus it is
treated as "default_version".
2) - linker reads c), get version "3.4.5", also regarded as default version,
because of "@@".
3) - linker segfaults at Symbol::override_version.
We only circumvent this if linker processes symbols in the order of a) -> b) ->
c). However the order linker processes symbols is out of our control.
Is there an usage error - providing a default version in both version script
file and object file?
But anyway, the link segfaul should be fixed.
(I think the explanation is clear to identify the problem, if not, I'll reduce
what I have and provide a small test case)
--
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/21491] --fix-cortex-a53-843419 Errata workaround can produce broken images
https://sourceware.org/bugzilla/show_bug.cgi?id=21491 --- Comment #3 from Han Shen --- (In reply to Cary Coutant from comment #2) > Fixed on trunk. Does this need to be backported? Yes, considering the severity of the bug. -- 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
