[Bug ld/20608] New: Relocation truncated to fit: R_ARM_THM_JUMP24 for relocation to PLT entry.
https://sourceware.org/bugzilla/show_bug.cgi?id=20608
Bug ID: 20608
Summary: Relocation truncated to fit: R_ARM_THM_JUMP24 for
relocation to PLT entry.
Product: binutils
Version: 2.25
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: peter.smith at linaro dot org
Target Milestone: ---
I'm raising this as a result of an investigation of a buildbot failure found
whilst trying to link libclang.so https://llvm.org/bugs/show_bug.cgi?id=27813
The exact error the buildbot was intermittently seeing was:
DebugHandlerBase.cpp:(.text._ZN4llvm8DenseMapIPKNS_12MachineInstrEPNS_8MCSymbolENS_12DenseMapInfoIS3_EENS_6detail12DenseMapPairIS3_S5_EEE4growEj[_ZN4llvm8DenseMapIPKNS_12MachineInstrEPNS_8MCSymbolENS_12DenseMapInfoIS3_EENS_6detail12DenseMapPairIS3_S5_EEE4growEj]+0x18a):
relocation truncated to fit: R_ARM_THM_JUMP24 against symbol `operator
delete(void*)@@GLIBCXX_3.4' defined in .text section in
/usr/lib/gcc/arm-linux-gnueabihf/4.8/libstdc++.so
collect2: error: ld returned 1 exit status
This sounds similar to https://sourceware.org/bugzilla/show_bug.cgi?id=12965
but that has been fixed for some time.
The failure on the buildbot is with binutils 2.24, but I've also reproducible
on 2.25 (the latest ARM build that I have available).
I don't have access to the original objects from the clang build, but I've made
a reproducer for what I think the problem is.
It needs a shared object or some other means of generating a PLT entry for a
symbol. The b.w instruction with the R_ARM_THUMB_JUMP24 relocation needs to be
in range of the ARM part of the PLT entry, but not in range of the inline Thumb
state change that the b.w needs to target. If the instruction is closer the b.w
can reach the inline state change, it the instruction is further away than the
ARM part then a stub is generated.
The test case is highly sensitive to the distance between the .plt entry and
the b.w. I'm using the (Linaro GCC 5.3-2016.02) 5.3.1 20160113 release.
-- shared.c --
int func(void) {
return 0;
}
arm-linux-gnueabihf-gcc shared.c --shared -fPIC -o shared.so
-- space.s --
.text
.syntax unified
.thumb
.global sp
.type sp,%function
.space (1024 * 1024 * 16) - 0x108
.space 2 // Will fail values 2 or 4
.global func2
.type func2,%function
func2:
b.w func
arm-linux-gnueabihf-gcc space.s -fPIC --shared -O2 -o test.axf shared.so
-mthumb
(.text+0xfffefa): relocation truncated to fit: R_ARM_THM_JUMP24 against symbol
`func' defined in .text section in shared.so
collect2: error: ld returned 1 exit status
--
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] New: --fix-cortex-a53-843419 Errata workaround can produce broken images
https://sourceware.org/bugzilla/show_bug.cgi?id=21491 Bug ID: 21491 Summary: --fix-cortex-a53-843419 Errata workaround can produce broken images Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: peter.smith at linaro dot org CC: ian at airs dot com Target Milestone: --- Created attachment 10051 --> https://sourceware.org/bugzilla/attachment.cgi?id=10051&action=edit Test case to reproduce the --ffix-cortex-843419 missing immediate The --fix-cortex-a53-843419 errata workaround extracts a ldr or str instruction of the form ld/st xt, [xn, #uimm] into an erratum stub. In certain circumstances the erratum stub extracts the instruction before it has been relocated leading to a ldr/str instruction in the stub with a 0 immediate, whereas if the patch were not applied the immediate would be non-0. This is likely to incorrect program, in our case a segfault at runtime. The root cause of the problem is when the erratum stubs for an output section are assigned to an input section from an object that is relocated before the object that contains the input section that needs the errata fix. In this case the stub table is relocated when the "owning" section is relocated, which can be before the section needing the patch is relocated (which updates the stub table) so the stub table contains the unrelocated instruction bit pattern. This is most likely (and how we encountered it) with LTO as the ELF object that comes back from the plugin is added last and has its relocations processed last. If the .text section from the LTO object needs a patch and the stub table "owner" is not from that LTO object then we observe the problem. I've attached a modification of the ld.bfd test erratum843419.s (add an immediate to extracted instruction) that can trigger this problem with a somewhat contrived linker script. Check the disassembly with the fix applied against the patch without the fix applied Original no fix: 2001004: f9008008str x8, [x0,#256] With fix: 2001004: 1408b 2001024 ... 02001020 : 2001020: d65f03c0ret 2001024: f908str x8, [x0] 2001028: 17f8b 2001008 Note that the #256 has been lost. I think that this is important as the android NDK enables the --fix-cortex-a53-843419 by default so any use of LTO within android is at risk. I suspect that this may be the root cause of https://sourceware.org/bugzilla/show_bug.cgi?id=21062 A possible workaround for LTO builds is to use a linker script and put the .text section from LTO into its own output section to make sure the owner of the stub table is the LTO object. -- 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/22233] [2.29 Regression] gold segfault in relocate_erratum_stub on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22233 Peter Smith changed: What|Removed |Added CC||peter.smith at linaro dot org --- Comment #1 from Peter Smith --- Created attachment 10587 --> https://sourceware.org/bugzilla/attachment.cgi?id=10587&action=edit Proposed patch to fix pr22233 and correct pr21868 -- 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/22233] [2.29 Regression] gold segfault in relocate_erratum_stub on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22233 --- Comment #2 from Peter Smith --- This is related to PR21868, the fix for that PR has a bug that triggers when the stub_owner section also needs erratum fixes. In this case the address of the thunks is not calculated correctly, resulting in a segfault for the example in this PR. This fault is also visible in the example for PR21868, although in that case it doesn't cause a segfault due to the incorrect address being within the bounds of the program. We can observe this in PR21868 by disassembling the shared library (from PR21868) with and without patches: Without patches: 5ffc: d0c0adrpx0, 1f000 <__FRAME_END__+0x16fa8> 6000: f946bc00ldr x0, [x0,#3448] 6004: f901d001str x1, [x0,#928] With patches: 5ffc: 100c8020adr x0, 1f000 <__FRAME_END__+0x16fa0> 6000: f946bc00ldr x0, [x0,#3448] 6004: f901d001str x1, [x0,#928] 8050: f901d001str x1, [x0,#928] 8054: 1400b 8054 We can see that the adrp at 5ffc has been converted to an adr. We can also see the addition of the patch at 8050 (the str to x1 has been copied). Note that the branch in the patch points to itself, if the fix_errata_and_relocate_erratum_stubs had been applied correctly then the b should have been to 0x6008 (after the str). Had the patch been more than an ADR range away from 0x5ffc (so the adrp to adr transformation could not be applied) then this would have caused a hang at run time. In the example attached to this case the incorrect address causes a segfault. I think that the offending bit of code is in fix_errata_and_relocate_erratum_stubs(). There is some code that detects when the (pview.is_input_output_view) is set, which means that the pview and pview.address need to be adjusted by the view_offset. Unfortunately this adjustment is missing in one case: stub_table->relocate_erratum_stub( stub, pview.view + view_offset + (stub_table->address() - pview.address)); Note that the pview.address on the last line is not adjusted for the view_offset so it will contain the base address of the output section and not the stub_table section. This will mean that relocate_erratum_stub gets the wrong address to relocate. I think that this function call should be: stub_table->relocate_erratum_stub( stub, pview.view + view_offset + (stub_table->address() - (pview.address + view_offset))); With this adjustment both PR21868 and the example in this PR look to be patched correctly. For people stuck with old versions of the tools possible workarounds are: - Compile with -ffunction-sections, this should reduce the size of sections which will lower the probability that the stub-owner needs patching. - Add or arrange for a non-zero sized input section that definitely does not need patches to be the end of the OutputSection. In most cases this seems to be one of the sections from crtn.o, crtendS.o, but in these examples they are of 0 size which prevents them from being the stub owner. -- 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/22233] [2.29 Regression] gold segfault in relocate_erratum_stub on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22233 --- Comment #4 from Peter Smith --- Thanks for the comment, I'll leave the patch as it is for now as I think it helps to have the view_offset added in each case. Happy to remove it if others prefer though. -- 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 Peter Smith changed: What|Removed |Added CC||peter.smith at linaro dot org --- Comment #3 from Peter Smith --- I have done some investigation and I think I have a fix for this PR. There are 2 separate problems with the --fix-cortex-a53-843419 shown up by the gitit build: - Internal fault when the address of erratum stubs is modified by the addition of stubs earlier in the output section, or previous output section. - Some erratum stubs are created but are not found, and hence skipped over, by fix_errata_and_relocate_erratum_stubs(). The root cause of this problem is that invalidate_erratum_stub() sets relobj_ to NULL. Unfortunately relobj is used in operator<() so the results of erratum_stubs_.lower_bound(), as used in find_erratum_stubs_for_input_section() are not reliable. The former can be exposed with a linker script or a very large test case such as gitit (requires 2 stub tables for the .text section). The latter is more likely to show up more when there are large numbers of erratum stubs, but in principle could happen in smaller examples so is more serious. I'll attach a couple of patches to address each of the problems. The first runs at the start of scan_errata(), it goes through each of the errata that have already been created on previous patches and updates each stub with its new erratum_address and destination_address. The second adds a new field valid_ that is not used in operator<() so it can be safely changed by invalidate_erratum_stub(). -- 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 --- Comment #4 from Peter Smith --- Created attachment 10649 --> https://sourceware.org/bugzilla/attachment.cgi?id=10649&action=edit Update erratum_stub addresses on each relaxation pass Attaching patch to fix the internal fault. The patch provides all the erratum_stubs with an up to date address on each relaxation pass. -- 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 --- Comment #5 from Peter Smith --- Created attachment 10650 --> https://sourceware.org/bugzilla/attachment.cgi?id=10650&action=edit Use a field that is not used in operator<() for erratum_stub validity Attached patch that adds a new field to class Erratum_stub, so that invalidate_erratum_stub can be used without affecting operator<(), which is used by erratum_stubs_.lower_bound(). -- 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 ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 Peter Smith changed: What|Removed |Added CC||peter.smith at linaro dot org --- Comment #5 from Peter Smith --- I think that the new error message for R_AARCH64_ABS32 from the linker makes some sense if the destination symbol is section relative as there is no dynamic relocation supported and truncating a 64-bit address is most likely a mistake. However if the destination symbol is absolute the linker shouldn't make the assumption that the symbol is an address so it should resolve the relocation at static link-time. I think the test: case BFD_RELOC_AARCH64_16: #if ARCH_SIZE == 64 case BFD_RELOC_AARCH64_32: #endif if (bfd_link_pic (info) && (sec->flags & SEC_ALLOC) != 0 && (sec->flags & SEC_READONLY) != 0) ... Give error message Should check that the symbol is not absolute as well. Unfortunately I can't think of a workaround for the case where the value of the symbols has to be in the RO-segment. For some reason the check only applies in RO sections, which does not make a lot of sense to me as a R_AARCH64_ABS32 from a RW section to an address will truncate it in the same way as if it were from a RO section. No dynamic relocation is generated for either RO or RW so I don't know why the distinction has been made. -- 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/22969] New: Add support for R_AARCH64_TLSLE_LDST8_TPREL_LO12 relocation.
https://sourceware.org/bugzilla/show_bug.cgi?id=22969 Bug ID: 22969 Summary: Add support for R_AARCH64_TLSLE_LDST8_TPREL_LO12 relocation. Product: binutils Version: unspecified Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: peter.smith at linaro dot org CC: ian at airs dot com Target Milestone: --- In a recent change to LLVM (https://reviews.llvm.org/D44355) an attempt was made to fold the add and the ldr in the sequence: mrs x1, TPIDR_EL0 add x2, x1, :tprel_hi12:local_exec_var add x3, x2, :tprel_lo12_nc:local_exec_var ldr w0, [x3] to: mrs x1, TPIDR_EL0 add x2, x1, :tprel_hi12:local_exec_var ldr w0, [x2, :tprel_lo12_nc:local_exec_var] Unfortunately for this to work support is needed for the R_AARCH_TLSLE_LDST8_TPREL_LO12 relocation that ldr w0, [x2, :tprel_lo12_nc:local_exec_var] uses. It looks like only R_AARCH64_TLSLE_ADD_TPREL_LO12 is supported in binutils trunk (gold and bfd right now). It would be nice to add support for that relocation to enable the relaxation. -- 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 ld/22970] New: Add support for R_AARCH64_TLSLE_LDST8_TPREL_LO12 relocation.
https://sourceware.org/bugzilla/show_bug.cgi?id=22970 Bug ID: 22970 Summary: Add support for R_AARCH64_TLSLE_LDST8_TPREL_LO12 relocation. Product: binutils Version: unspecified Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: peter.smith at linaro dot org Target Milestone: --- This enhancement has the same text as: https://sourceware.org/bugzilla/show_bug.cgi?id=22969 but applies to ld.bfd and not ld.gold. In a recent change to LLVM (https://reviews.llvm.org/D44355) an attempt was made to fold the add and the ldr in the sequence: mrs x1, TPIDR_EL0 add x2, x1, :tprel_hi12:local_exec_var add x3, x2, :tprel_lo12_nc:local_exec_var ldr w0, [x3] to: mrs x1, TPIDR_EL0 add x2, x1, :tprel_hi12:local_exec_var ldr w0, [x2, :tprel_lo12_nc:local_exec_var] Unfortunately for this to work support is needed for the R_AARCH_TLSLE_LDST8_TPREL_LO12 relocation that ldr w0, [x2, :tprel_lo12_nc:local_exec_var] uses. It looks like only R_AARCH64_TLSLE_ADD_TPREL_LO12 is supported in binutils trunk (gold and bfd right now). It would be nice to add support for that relocation to enable the relaxation. -- 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 ld/22970] Add support for R_AARCH64_TLSLE_LDST8_TPREL_LO12 relocation.
https://sourceware.org/bugzilla/show_bug.cgi?id=22970 --- Comment #2 from Peter Smith --- Hello Nick, Thanks for the patch. I'm travelling at the moment; I will try this out when I get back to the office on Monday. Peter -- 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 ld/22970] Add support for R_AARCH64_TLSLE_LDST8_TPREL_LO12 relocation.
https://sourceware.org/bugzilla/show_bug.cgi?id=22970 --- Comment #3 from Peter Smith --- Hello Nick, I've been able to try out the patch. It looks like it is doing what I'd expect for the R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC relocation. When I went back to the original LLVM patch, I tried the example and got a missing relocation error. It looks like my PR was incomplete; I missed out: R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC These correspond to the halfword, 32-bit and 64-bit word load instructions (the LDST8 is the byte load instruction). My apologies for missing these out, would it be possible to consider these as well as they could be generated by a compiler with the same llvm patch? An example to that can be assembled with clang --target=aarch64-linux-gnu generates these relocations. .text .globl _start .type _start, %function _start: mrs x8, TPIDR_EL0 add x8, x8, :tprel_hi12:var0 ldr x0, [x8, :tprel_lo12_nc:var0] add x8, x8, :tprel_hi12:var1 ldr w0, [x8, :tprel_lo12_nc:var1] add x8, x8, :tprel_hi12:var2 ldrh w0, [x8, :tprel_lo12_nc:var2] add x8, x8, :tprel_hi12:var3 ldrb w0, [x8, :tprel_lo12_nc:var3] .globl var0 .globl var1 .globl var2 .globl var3 .type var0,@object .type var1,@object .type var2,@object .type var3,@object .section.tbss,"awT",@nobits .p2align2 var0: .quad 0 .size var1, 8 var1: .word 0 .size var1, 4 var2: .hword 0 .size var2, 2 var3: .byte 0 .size var3, 1 -- 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/24642] New: Gold missing armv8 from may_use_v5t_interworking() results in less efficient v4t stubs
https://sourceware.org/bugzilla/show_bug.cgi?id=24642
Bug ID: 24642
Summary: Gold missing armv8 from may_use_v5t_interworking()
results in less efficient v4t stubs
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: peter.smith at linaro dot org
CC: ian at airs dot com
Target Milestone: ---
In arm.cc the code that permits v5t interworking instructions is missing a case
for TAG_CPU_ARCH_V8 and the various V8_M mainline and baseline. As
--fix-arm1176 is the default this means that gold is using v4t stubs for arm v8
cpus. This is not a problem for correctness but v4t stubs and the non-use of
BLX is likely to have a measurable code-size and performance impact.
This can be worked around with -fno-fix-arm1176 but it should be simple to fix.
// Whether we have v5T interworking instructions available.
bool
may_use_v5t_interworking() const
{
Object_attribute* attr =
this->get_aeabi_object_attribute(elfcpp::Tag_CPU_arch);
int arch = attr->int_value();
if (parameters->options().fix_arm1176())
return (arch == elfcpp::TAG_CPU_ARCH_V6T2
|| arch == elfcpp::TAG_CPU_ARCH_V7
|| arch == elfcpp::TAG_CPU_ARCH_V6_M
|| arch == elfcpp::TAG_CPU_ARCH_V6S_M
|| arch == elfcpp::TAG_CPU_ARCH_V7E_M);
else
return (arch != elfcpp::TAG_CPU_ARCH_PRE_V4
&& arch != elfcpp::TAG_CPU_ARCH_V4
&& arch != elfcpp::TAG_CPU_ARCH_V4T);
}
A reproducer:
// call.c
extern void func1(void);
void func2(void) {
func1();
}
arm-linux-gnueabihf-gcc call.c -mthumb -o call.so --shared -fuse-ld=gold
-march=armv8-a -fpic
arm-linux-gnueabihf-objdump -d --no-show-raw-insn call.so
04c0 :
4c0: push{r7, lr}
4c2: add r7, sp, #0
4c4: bl 4cc
4c8: nop
4ca: pop {r7, pc}
4cc: bx pc
4ce: nop ; (mov r8, r8)
4d0: stmia r0!, {}
4d2: b.n 14 <_init-0x344>
4d4: blx 40f5f0 <_end+0x40d5c3>
4d8: mrc215, 5, pc, cr4, cr15, {7}
You can see the "bx pc" followed by "nop" of the v4t stub.
The stmia is Arm instructions disassembled as Thumb because there is no mapping
symbol to inform the disassembler that the state has changed.
--
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
