Go to file
Thomas Petazzoni 4210c49357 binutils: add patch to fix AArch64 glibc build issue
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>
2014-05-16 09:55:21 +02:00
arch arch/arm: drop ARM(7TDMI/720T/740T) support 2014-05-08 16:53:49 +02:00
board qemu x86/x86_64: Add kernel IPC support 2014-05-09 16:29:26 +02:00
boot barebox: bump to version 2014.05.0 2014-05-12 22:22:17 +02:00
configs configs: bump kernel used for the RPi 2014-05-09 16:30:01 +02:00
docs Update for 2014.05-rc1 2014-05-13 10:49:03 +02:00
fs fs: use our own tools when calling the fakerooted script 2014-05-11 10:51:28 +02:00
linux linux: bump to version 3.14.4 2014-05-14 09:31:08 +02:00
package binutils: add patch to fix AArch64 glibc build issue 2014-05-16 09:55:21 +02:00
support pkg-stats: fix whitespaces 2014-05-15 23:38:20 +02:00
system system/Config.in: fix custom skeleton help text 2014-05-02 09:25:02 +02:00
toolchain toolchain-external: Sourcery CodeBench ARM 2013.05 affected by PR58595 2014-05-12 23:53:05 +02:00
.defconfig buildroot: get rid of s390 support 2009-01-12 14:36:14 +00:00
.gitignore update gitignore 2013-05-04 12:41:55 +02:00
CHANGES Update for 2014.05-rc1 2014-05-13 10:49:03 +02:00
Config.in kernel headers: remove deprecated versions 3.6 and 3.7 2014-05-01 23:35:06 +02:00
Config.in.legacy evtest: bump version to 1.31 2014-05-03 22:56:31 +02:00
COPYING clarify license and fix website license link 2009-05-08 09:29:41 +02:00
Makefile Update for 2014.05-rc1 2014-05-13 10:49:03 +02:00
Makefile.legacy Makefile.legacy: fix recursive invocation with BUILDROOT_DL_DIR and _CONFIG 2014-02-11 08:14:57 +01:00
README docs: Move README file to root 2014-03-03 21:28:39 +01:00

To build and use the buildroot stuff, do the following:

1) run 'make menuconfig'
2) select the packages you wish to compile
3) run 'make'
4) wait while it compiles
5) Use your shiny new root filesystem. Depending on which sort of
    root filesystem you selected, you may want to loop mount it,
    chroot into it, nfs mount it on your target device, burn it
    to flash, or whatever is appropriate for your target system.

You do not need to be root to build or run buildroot.  Have fun!

Offline build:
==============

In order to do an offline-build (not connected to the net), fetch all
selected source by issuing a
$ make source

before you disconnect.
If your build-host is never connected, then you have to copy buildroot
and your toplevel .config to a machine that has an internet-connection
and issue "make source" there, then copy the content of your dl/ dir to
the build-host.

Building out-of-tree:
=====================

Buildroot supports building out of tree with a syntax similar
to the Linux kernel. To use it, add O=<directory> to the
make command line, E.G.:

$ make O=/tmp/build

And all the output files (including .config) will be located under /tmp/build.

More finegrained configuration:
===============================

You can specify a config-file for uClibc:
$ make UCLIBC_CONFIG_FILE=/my/uClibc.config

And you can specify a config-file for busybox:
$ make BUSYBOX_CONFIG_FILE=/my/busybox.config

To use a non-standard host-compiler (if you do not have 'gcc'),
make sure that the compiler is in your PATH and that the library paths are
setup properly, if your compiler is built dynamically:
$ make HOSTCC=gcc-4.3.orig HOSTCXX=gcc-4.3-mine

Depending on your configuration, there are some targets you can use to
use menuconfig of certain packages. This includes:
$ make HOSTCC=gcc-4.3 linux-menuconfig
$ make HOSTCC=gcc-4.3 uclibc-menuconfig
$ make HOSTCC=gcc-4.3 busybox-menuconfig

Please feed suggestions, bug reports, insults, and bribes back to the
buildroot mailing list: buildroot@buildroot.org