Binutils 2.24 produces broken code when compiling the kernel for
ppc64le, so prevent this combination. See:
https://sourceware.org/ml/binutils/2013-12/msg00200.html
The problem manifests early in the boot process with "Kernel access of
bad area, sig: 11" in arch_match_cpu_phys_id().
The fix has been merged upstream as commit
57fa7b8c7e59e35bced580f9bcb9668af43fdbce, which is available since
Binutils 2.25.
Signed-off-by: Sam Bobroff <sam.bobroff@au1.ibm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
In buildroot we maintain a couple off-the-tree patches.
In particular for binutils and gcc packages.
Because we have many versions of mentioned packages patches for each
particular version reside in a folder which name matches full version
name of the package.
For example we used to have patches for binutils distributed as part of
arc-2014.12 tools in folder ""package/binutils/arc-2014.12". Now with
bump of ARC tools version we need to rename folder with patches to
"arc-2015.06-rc1".
The same applies to gcc.
Should fix http://autobuild.buildroot.net/results/2b2/2b27a4a64c0b225ae479ecfccf7a97f5ea95598c/
As discussed before it's not possible to reproduce reported problem on recent
Fedora 21/22 distros (at least we know about them) but I may confirm that
patches were applied fine and everything was built well. Hopefully reported
build failure goes away now.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Romain Naour <romain.naour@openwide.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Following commit 36555b4c8d ("ARC:
switch to RC1 of upcoming arc-2015.06 tools"), the binutils package
only contains the hash information for the 2015.06-rc1 ARC version of
binutils (which is in fact no hash). However, when an external
toolchain is used, and binutils is built for the target, it's still
the old 2014.11 binutils version that gets used in binutils.mk,
causing a build failure because there is no hash available for this
version.
This commit fixes that by using 2015.06-rc1 as the default binutils
version on ARC, which is used when no host-binutils has been built.
Fixes:
http://autobuild.buildroot.org/results/8f7/8f772e6fccb4f918120a7bb814da2224432d1c09/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Even though this is only RC1 it's been heavily used internally so it should
not be any worse than existing arc-2014.12.
Moreover this relase (and so its RC1) finally delivers support of NPTL
for ARC in uClibc.
That's why it would be good to allow interested users to start trying it
(for example WebKit and apps that use WebKit could be successfully built
and run) also it will be helpful to run that new toolchain through
autobuilder in attempt to find any hidden regressions so we have a solid
toolchain for release.
If there's an interest in that patch more patches will follow with
subsequent RCs and essentially on appearence or relese Buildroot will be
updated with it.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
elf_xtensa_gc_sweep_hook doesn't correctly unreference symbols that were
made local, that results in link failure with the following message:
BFD (GNU Binutils) 2.24 internal error, aborting at elf32-xtensa.c line
3372 in elf_xtensa_finish_dynamic_sections
elf_xtensa_gc_sweep_hook determines symbol reference type (PLT or GOT) by
relocation type. Relocation types are not changed when symbol becomes
local, but its PLT references are added to GOT references and
plt.refcount is set to 0. Such symbol cannot be unreferences in the
elf_xtensa_gc_sweep_hook and its extra references make calculated GOT
relocations section size not match number of GOT relocations.
Fix it by treating PLT reference as GOT reference when plt.refcount is
not positive.
Fixes:
http://autobuild.buildroot.net/results/3e2e24f697e26c93d4d95782b1cb7799fa620a7a/http://autobuild.buildroot.org/results/97d4c96d6f6cdc1ed4007456f4ab70be9dfa41b5/
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
--disable-install-libiberty configure option is broken
in gcc 4.8.x, so libiberty.a is always installed in HOST_DIR.
This library broke the host-gdb build due to a fpic/fPIC issue.
Since binutils use a copy of gcc's libiberty sources, it's
affected by the same bug.
binutils-arc-2014.11 which is based on 2.23 branch doesn't have
the PR56780 fixies, so backport them.
Fixes:
http://autobuild.buildroot.net/results/ca4/ca45297aa0ffbc9062ed92dc7ac070b0b33001de/
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
xtensa trampolines relaxation optimization caused the following build
errors:
Error: operand 1 of 'j' has out of range value '131643'
Error: operand 1 of 'j' has out of range value '4294836162'
Error: operand 1 of 'j' has out of range value '4294836072'
Extra condition 'abs (addr - trampaddr) < J_RANGE / 2' for trampoline
selection results in regressions: when relaxable jump is little longer
than J_RANGE so that single trampoline makes two new jumps, one longer
than J_RANGE / 2 and one shorter, correct trampoline cannot be found.
Drop that condition.
Upstream status: patch submitted.
Fix squashed into the optimization patch.
Fixes:
http://autobuild.buildroot.net/results/5ba7d18262ce6a2dfd69db07d064a971267f1128/
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This optimization alone reduces gnuradio build time for xtensa from 2
hours to 40 minutes.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This series optimizes most time-consuming algorithms and data structures
in the xtensa link-time relaxation code, leaving relaxation logic intact.
Speedup linking typical linux kernel is ~8 times (1 minute instead of 8),
pathological cases (linking objects partially linked without relaxation)
are handled ~60 times faster (1 minute instead of an hour).
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now that we don't support the internal blackfin toolchain any more
remove unnecessary conditionals.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When an external toolchain is used on ARC, BR2_BINUTILS_VERSION is
undefined, so we use binutils 2.22, which doesn't support ARC and
anyway isn't available from the ARC download location.
So, let's defined a default ARC binutils version in binutils.mk.
Fixes:
http://autobuild.buildroot.org/results/52a/52abadacd7aab2d5c11d094937f28198bf220662/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Add a new option BR2_GCC_ENABLE_LTO that builds gcc and binutils with
LTO support.
Individual packages still have to enable LTO explicitly by passing '-flto' to
GCC, which passes it on to the linker. This option does not add that flag
globally. Some packages detect if the compiler supports LTO and enable the flag
if it does.
To support LTO, ar and ranlib must be called with an argument which triggers the
usage of the LTO plugin. Since GCC doesn't call these tools itself, it instead
provides wrappers for ar and ranlib that pass the LTO arguments. This way
existing Makefiles don't need to be changed for LTO support. However, these
wrappers are called <tuple>-gcc-ar which matches the pattern to link to the
buildroot wrapper in the external toolchain logic. So the external toolchain
logic is updated to provide the correct symlink.
[Thomas:
- Add a separate BR2_BINUTILS_ENABLE_LTO option to enable LTO
support in binutils. This is a blind option, selected by
BR2_GCC_ENABLE_LTO. It just avoids having binutils.mk poke
directly into gcc Config.in options.
- Remove the check on the AVR32 special gcc version, which we don't
support anymore.
- Adapt the help text of the LTO Config.in option to no longer
mention "Since version 4.5", since we only support gcc >= 4.5 in
Buildroot anyway.
- Fix typo in toolchain-external.mk comment.]
Signed-off-by: Peter Kümmel <syntheticpp@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Versions previous to binutils v2.25 do not support the Nios-II architecture,
so disable them.
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Now when new shiny tools are released by Synopsys we're ready for
version update in Buildroot again.
More details about arc-2014.12 release are available here:
https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2014.12
Following patches were removed from GCC since they are a part of release
now:
* 200-size_type_unsigned_int.patch
* 300-ptrdiff_type_int.patch
* 400-call-arc_hazard-before-branch-shortening.patch
* 401-fix-length-attribute-for-casesi_load-pattern.patch
* 402-fix-length-of-instructions-that-are-in-delay-slot-and-needs-to-be-predicated.patch
* 403-update-casesi_compact_jump-instruction-length.patch
But since arc-2014.12 tools are still based on GCC 4.8 following patches
ar still relevant so moving to the new folder to match ARC gcc bump.
* 100-libstdcxx-uclibc-c99.patch
* 910-gcc-poison-system-directories.patch
Binutils are still based on 2.23 so following patch still makes sense:
* 600-poison-system-directories.patch
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This library will be used later in the "lightning" package.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2.22 is getting quite old (Nov 2011) and we've recently added 2.25. 2.24 has
been used for the "new" architectures for a while and there's no known
issues going to 2.24 for the rest, so bump the default version.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit enables the poison system directories option, which is now
available thanks to the binutils patches that have been added.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Acked-by: Romain Naour <romain.naour@openwide.fr>
Tested-by: Romain Naour <romain.naour@openwide.fr>
This commit adds a patch to binutils borrowed from CodeSourcery/Yocto
that warns about unsafe library paths (i.e /usr/lib, /usr/local/lib,
etc.). The patch was adapted to binutils arc-2014.08, and modified to
support the BR_COMPILER_PARANOID_UNSAFE_PATH environment variable to
error out instead of just warn when unsafe paths are used. Even though
erroring out can be chosen by passing
--error-poison-system-directories, we are not sure this option in
LDFLAGS will always be passed, so having an environment variable
guarantees it will always be passed, and also allows to have an
identical behavior to the external toolchain wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Romain Naour <romain.naour@openwide.fr>
This commit adds a patch to binutils borrowed from CodeSourcery/Yocto
that warns about unsafe library paths (i.e /usr/lib, /usr/local/lib,
etc.). The patch was adapted to binutils 2.22, and modified to support
the BR_COMPILER_PARANOID_UNSAFE_PATH environment variable to error out
instead of just warn when unsafe paths are used. Even though erroring
out can be chosen by passing --error-poison-system-directories, we are
not sure this option in LDFLAGS will always be passed, so having an
environment variable guarantees it will always be passed, and also
allows to have an identical behavior to the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Romain Naour <romain.naour@openwide.fr>
This commit adds a patch to binutils borrowed from CodeSourcery/Yocto
that warns about unsafe library paths (i.e /usr/lib, /usr/local/lib,
etc.). The patch was adapted to binutils 2.23, and modified to support
the BR_COMPILER_PARANOID_UNSAFE_PATH environment variable to error out
instead of just warn when unsafe paths are used. Even though erroring
out can be chosen by passing --error-poison-system-directories, we are
not sure this option in LDFLAGS will always be passed, so having an
environment variable guarantees it will always be passed, and also
allows to have an identical behavior to the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Romain Naour <romain.naour@openwide.fr>
This commit adds a patch to binutils borrowed from CodeSourcery/Yocto
that warns about unsafe library paths (i.e /usr/lib, /usr/local/lib,
etc.). The patch was adapted to binutils 2.24, and modified to support
the BR_COMPILER_PARANOID_UNSAFE_PATH environment variable to error out
instead of just warn when unsafe paths are used. Even though erroring
out can be chosen by passing --error-poison-system-directories, we are
not sure this option in LDFLAGS will always be passed, so having an
environment variable guarantees it will always be passed, and also
allows to have an identical behavior to the external toolchain
wrapper.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Romain Naour <romain.naour@openwide.fr>
[Thomas: re-adjust dependencies, according to Yann's comment.]
Signed-off-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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>
binutils starting at least from 2.23 when build for target require
uClibc configured with UCLIBC_HAS_WCHAR otherwise:
libtool: link: [...] -o as-new [...]
read.o: In function `read_symbol_name':
read.c:(.text+0x3634): undefined reference to `mbstowcs'
collect2: error: ld returned 1 exit status
because "mbstowcs" is not available in the C library.
Even though we're not yet using 2.23.2 as the default version, we will
probably do it in the near future, so this commit doesn't bother with
making the wchar dependency version-specific, and applies it to the
binutils package as a whole.
Fixes bug #6218
[Thomas:
- more details in the commit log.
- add comment about the wchar dependency
- propagate the dependency to dropwatch (and fix a mistake in the
architecture dependencies of the comment)
- propagate the dependency to oprofile.]
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
When binutils for the host is not built (which is the case when an
external toolchain is used), the version of binutils used is 2.21,
which is quite old. Since we have bumped to 2.22 as the default
version for the host binutils, let's do the same for the target
binutils.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
We no longer have any way of using version 2.23, and all the other
versions that we support are available as .tar.bz2. Therefore we can
remove the special case related to the 2.23 version only being
available as a .tar.gz archive.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
make the same change for FOO_CONF_OPT.
Sed command used:
find * -type f | xargs sed -i 's#_CONF_OPT\>#&S#g'
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.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>
You get following linking error, when trying to build a
toolchain for bfin with newer binutils:
bfin-buildroot-linux-uclibc/bin/ld: fde encoding in _divdi3_s.o(.eh_frame) prevents .eh_frame_hdr table being created.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now when new shiny tools are released by Synopsys we're ready for version
update in Buildroot.
Important change in this release is switching to combined "binutils-gdb" repo
in accordance to upstream move.
Following patch now is a part of the most recent relese:
e6ab8cac62
So dropping it.
package/binutils/arc-4.8-R3/0001-arc-Honor-DESTDIR-in-custom-Makefile.patch
Since arc-2014.08 tools are still based on GCC 4.8 following patch is still
relevant so moving to the new folder to matxh ARC gcc bump.
package/gcc/arc-4.8-R3/100-libstdcxx-uclibc-c99.patch ->
package/gcc/arc-2014.08/100-libstdcxx-uclibc-c99.patch
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
If Binutils and/or GDB are fetched from the unified binutils-gdb
repository, then the tarball will contain both Binutils and GDB
sources, unlike the "normal" tarballs that contain only the titular
package. To keep packages separated in Buildroot we need to disable
undesired components when configuring.
Binutils and GDB migrated to a common Git repository in the October
2013 [1]. Previous Git repositories were incomplete copies of CVS
repository which copied only the relevant files (no binutils files in
GDB, and vice versa). In the new binutils-gdb repository there is no
such separation and a result all files exist in directory after
checkout. So if "configure" and "make" are used without explicit
targets, all projects will be built: binutils, ld, gas, bfd, opcodes,
gdb, etc. In case of Buildroot this would mean that selecting Binutils
only, still will build both Binutils and GDB. And if GDB is selected
as well, then both packages will be built two times, and Binutils from
GDB directory will overwrite initial build of Binutils (or vice versa
if Binutils will be built after the GDB). This is a serious problem,
because binutils and GDB use separate branches in this common
repository. In case of Buildroot this means that separate Git commits
(or tags) should be used when downloading source from Git.
This affects only Git repositories, because GNU release tarballs still
contain only relevant packages.
This change is backward compatible, because if "normal" tarball is
used (without extra directories), than --disable-* configure options
are just ignored by configure.
[1] https://sourceware.org/ml/gdb/2013-10/msg00071.html
[Thomas: use variables to factorize options, and add comments in the
relevant .mk files to explain what's going on.]
Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
After the following commits:
26974bf6a7 use default binutils for sh architecture
6f1cf344d9 binutils: Use the default version by default on MIPS
the 2.21.1 binutils version is no longer required, and since it's an
old version, we get rid of it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Following d4839ffcab ("binutils: remove
2.20.1, 2.21 and 2.23.1"), Config.in.host contains unneeded
definitions of BR2_BINUTILS_VERSION for no longer existing
versions. This patch fixes that.
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 2.20.x series is old, it no longer makes sense to support it.
- In the 2.21.x series, we still have 2.21.1, so keeping 2.21 doesn't
make much sense, so this patch removes it.
- Similarly for the 2.23.x series, having both 2.23.1 and 2.23.2
doesn't make much sense, so this patch removes 2.23.1 and keeps
2.23.2.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Tested toolchain compiles with binutils 2.22 and 2.24.
Result tested in Qemu 2.0.0. (only little endian version
tested)
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
makeinfo is known to cause problems when building old texi files with more
recent host makeinfo.
In particular binutils-2.18 won't build on Fedora 20 without this change.
Even though more up to date binutils does build without this change there's
no guaranty it will with bump of host makeinfo in the future.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Anton Kolesov <akolesov@synopsys.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
ARC-specific Makefile has been ignoring DESTDIR when doing target "install".
This has been causing build failure for native binutils, since it was trying
to install into the host's "/usr". This commit adds a patch that teaches
Makefile to honor DESTDIR. This patch should be removed after ARC Binutils
will be bumped to next release.
This fixes:
http://autobuild.buildroot.net/results/68ee094509db3e8fbedf9bab5745ff68cdfe0a84/
Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch adds support for powerpc64le-linux-gnu. This includes
needed patches to fakeroot and gmp.
gmp patch is from upstream HG tree.
fakeroot patch is from Ubuntu written by Adam Conrad.
Signed-off-by: Jeff Bailey <jeffbailey@google.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.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>
