This fixes the following build errors seen when assembling huge files
produced by gcc:
Error: jump target out of range; no usable trampoline found
Error: operand 1 of 'j' has out of range value '307307'
Fixes:
http://autobuild.buildroot.net/results/545/545168d9caf3bdb3dd3eb3bae58ba9db8a33384a/
Backported from: d92b6eece424f0ad35d96fdd85bf207295e8c4c3
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This fixes the following linux kernel build errors:
LD init/built-in.o
net/built-in.o: In function `raw_proc_exit':
(.init.text+0xe29): dangerous relocation:
call8: call target out of range: udp_proc_register
net/built-in.o: In function `udp_table_init':
(.init.text+0xf09): dangerous relocation:
call8: call target out of range: udp_proc_register
net/built-in.o: In function `inet_init':
af_inet.c:(.init.text+0x142e): dangerous relocation:
call8: call target out of range: udp4_proc_exit
net/built-in.o: In function `ip_auto_config':
ipconfig.c:(.init.text+0x28aa): dangerous relocation:
call8: call target out of range: arp_send
Backported from: 331ed1307b93d3ff77d248bdf2f7b79a20851457
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This fixes the following build error reproducible with any linux kernel
module built with a recent buildroot toolchain:
LD [M] fs/jbd2/jbd2.ko
/bin/sh: line 1: 12069 Segmentation fault
buildroot/host/usr/bin/xtensa-buildroot-linux-uclibc-ld -r --no-relax
-T linux/scripts/module-common.lds --build-id
-o fs/jbd2/jbd2.ko fs/jbd2/jbd2.o fs/jbd2/jbd2.mod.o
Backported from: e7d17e71cdc10a2e81e454ce3b9637f1b2a587f2
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The autobuilders are not able to build glibc on AArch64 since we moved
to the internal toolchain backend as the default for AArch64. The
reason is that the cross-ld segfaults while linking of the glibc
utilities. Unfortunately, the issue has so far been impossible to
reproduce outside of the autobuilder CI loop itself: even on the same
machine, in the same chroot, the issue does not appear.
Today, Will Newton helped me analyze a bit further the problem. In the
logs of the build machine, we have found that the following segfault
notification matched the dates of the autobuilder failures:
/var/log/syslog:May 15 10:39:20 sd-56966 kernel: [767023.832598] ld[6846]: segfault at 1b2c002 ip 00000000004caf80 sp 00007fffaa308df8 error 4 in ld[400000+1b9000]
/var/log/syslog.2.gz:May 13 07:58:24 sd-56966 kernel: [585094.434264] ld[17761]: segfault at 154b002 ip 00000000004caf80 sp 00007fff0d400168 error 4 in ld[400000+1b9000]
/var/log/syslog.3.gz:May 12 20:24:08 sd-56966 kernel: [543558.227915] ld[14841]: segfault at 2706002 ip 00000000004caf80 sp 00007fffc08d41c8 error 4 in ld[400000+1b9000]
/var/log/syslog.4.gz:May 11 19:51:59 sd-56966 kernel: [455484.523033] ld[50162]: segfault at 1f00002 ip 00000000004caf80 sp 00007fff14a02328 error 4 in ld[400000+1b9000]
/var/log/syslog.4.gz:May 12 05:13:37 sd-56966 kernel: [489085.120089] ld[32067]: segfault at 2430002 ip 00000000004caf80 sp 00007fffc448db48 error 4 in ld[400000+1b9000]
/var/log/syslog.6.gz:May 9 15:20:38 sd-56966 kernel: [266948.197141] ld[13483]: segfault at ff0002 ip 00000000004caf80 sp 00007fff7e4fe948 error 4 in ld[400000+1b9000]
/var/log/syslog.7.gz:May 8 16:45:08 sd-56966 kernel: [185853.688607] ld[1757]: segfault at 20b1002 ip 00000000004caf80 sp 00007fffd07d5ae8 error 4 in ld[400000+1b9000]
See
http://autobuild.buildroot.org/?reason=glibc-2.18-svnr23787&arch=aarch64
for the autobuilder results.
So, the segfault always happens while accessing an address 2 bytes
after the beginning of a page: it looks like a buffer overflow, which
gets triggered because the object is placed towards the end of the
previous page, and crosses over the next, unallocated page.
Moreover, we looked at the 0x4caf80 address in an AArch64 cross-ld
built by Buildroot, and it turns out that it is part of the
iterative_hash() function. This nicely correlates with the patch that
Will Newton had pointed in
http://lists.busybox.net/pipermail/buildroot/2014-May/095881.html as a
fix for invalid memory accesses reported by Valgrind in the AArch64
cross-ld, specifically around the same area of 'ld'.
Therefore, even though we have not been able to reproduce the issue
outside of the autobuilders, and cannot confirm that the patch is
fixing the issue, I propose to integrate this binutils patch into
Buildroot. It is anyway an upstream binutils patch, which fixes a real
problem.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This fixes the following build error often seen during linux kernel
linking step with relaxation enabled:
dangerous relocation: call8: misaligned call target: (.text.unlikely+0x63)
Backported from: a35d5e823fdfe8a6e7e05ca8e3fb8bb5697335b1
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Rebuilding as.info with makeinfo version 5.2 results in a build error,
even with pristine binutils source. Dropping hunks that change *.texi*
files avoids documentation rebuild.
Reported-by: Vincent Stehlé <vincent.stehle@freescale.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This fixes compilation of huge source files that have jumps with offsets
greater than 128 Kbytes, that otherwise fails with such messages:
{standard input}:65267: Error: operand 1 of 'j' has out of range value '131089'
{standard input}:106879: Error: operand 1 of 'j' has out of range value '4294833951'
Fixes:
http://autobuild.buildroot.net/results/e45/e450d5efc7435035c956bb962d598837648f319d/
Backported from: a82c7d9030b67a6a76a5403d0e1641f9e42141ac
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes http://autobuild.buildroot.org/results/1ea/1ea98985ce06dc1b7569ef5abe2fc13090fb5f3a
The upstream patch patches both configure.ac and configure, so we keep
that.
It is numbered 001 because it is an upstream patch, so it should come
before the buildroot patches.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Max Filippov
Thomas Petazzoni
Arnout Vandecappelle
Gustavo Zacarias