buildroot/toolchain/toolchain-wrapper.c, branch 2016.11

arch/Config.in.mips: add support for XBurst cores

2016-11-09T20:36:34+00:00

The Ingenic XBurst is a MIPS32R2 microprocessor. It has a bug in the FPU that can generate incorrect results in certain cases. The problem shows up when you have several fused madd instructions in sequence with dependant operands. Using the -mno-fused-madd option prevents gcc from emitting these instructions. This patch adds changes to the toolchain wrapper to use that option. Signed-off-by: Vicente Olivert Riera Signed-off-by: Thomas Petazzoni

toolchain/wrapper: extend paranoid check to -isystem

2016-09-18T14:09:23+00:00

Some packages, like libbsd, use -isystem flags to provide so-called overrides to the system include files. In this particular case, this is used in a .pc file, then used by antoher package; pkgconf does not mangle this path; and eventually that other package ends up using /usr/include/bsd to search for headers. Our current toolchain wrapper is limited to looking for -I and -L, so the paranoid check does not kick in. Furthermore, as noticed by Arnout, there might be a bunch of other so-unsafe options: -isysroot, -imultilib, -iquote, -idirafter, -iprefix, -iwithprefix, -iwithprefixbefore; even -B and --sysroot are unsafe. Extend the paranoid check to be able to check any arbitrary number of potentially unsafe options: - add a list of options to check for, each with their length, - iterate over this list until we find a matching unsafe option. Compared to previously, the list of options include -I and -L (which we already had) extended with -idirafter, -iquote and -isystem, but leaving all the others noticed by Arnout away, until we have a reason for handling them. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Signed-off-by: Thomas Petazzoni

toolchain/wrapper: display options leading to a paranoid failure

2016-09-18T14:07:35+00:00

Current, we only display the path that causes the paranoid failure. This is sufficient, as we can fail only for -I and -L options, and it is thus easy to infer from the path, which option is the culprit. However, we're soon to add a new test for the -isystem option, and then when a failure occurs, we would not know whether it was because of -I or -isystem. Being able to differentiate both can be hugely useful to track down the root cause for the unsafe path. Add two new arguments to the check_unsafe_path() function: one with the current-or-previous argument, one to specify whether it has the path in it or not. Print that in the error message, instead of just the path. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Signed-off-by: Thomas Petazzoni

arch/x86: add support for Intel X1000

2015-10-20T08:04:52+00:00

The Intel X1000 is the Pentium class microprocessor that ships with Galileo Gen 1/2. This patch adds changes to arch and toolchain-wrapper to omit the lock prefix for the X1000. [Thomas: tweak commit log and Config.in help text.] Signed-off-by: Ray Kinsella Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

toolchain-external: bypass buildroot wrapper

2015-10-17T08:50:35+00:00

The buildroot internal toolchain now adds a wrapper. When we use a buildroot toolchain as an external toolchain, we want to bypass this wrapper and call the compiler directly, for two reasons: 1. The options added by the wrapper are not necessarily appropriate when it is reused as an external toolchain. For instance, ccache may have been enabled while building the toolchain but not when using it as an external toolchain. 2. Currently, the wrapper expects to reside in .../usr/bin, but when used as an external toolchain it will be in .../ext-toolchain/bin. Therefore, the wrapper can't find the real binary and sysroot anymore. To bypass the wrapper, we check for the existence of *.br_real files in the external toolchain directory. If any such file exists, the wrapper will add the .br_real suffix for all the wrapped files. Note that the wrapper doesn't check if the *.br_real exists for each individual wrapped file, it just assumes that all wrapped files have a corresponding .br_real. This is currently true but that may change in the future of course. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

toolchain-wrapper.c: unbreak BR_CROSS_PATH_ABS handling

2015-10-05T06:25:17+00:00

Fixes #8386 We should check if BR_CROSS_PATH_ABS is defined, not if it evalutates to true for the pre processor. Signed-off-by: Peter Korsgaard

ccache: support changing the output directory

2015-10-04T16:22:21+00:00

When building in a different output directory than the original build, there will currently be a lot of ccache misses because in many cases there is some -I/... absolute path in the compilation. Ccache has an option CCACHE_BASEDIR to substitute absolute paths with relative paths, so they wil be the same in the hash (and in the output). Since there are some disadvantages to this path rewriting, it is made optional as BR2_CCACHE_USE_BASEDIR. It defaults to y because the usefulness of ccache is severely reduced without this option. In addition to CCACHE_BASEDIR, we also substitute away the occurences of $(HOST_DIR) in the calculation of the compiler hash. This is done regardless of the setting of BR2_CCACHE_USE_BASEDIR because it's quite harmless. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

ccache: use mtime for external toolchain, CONF_OPTS for internal toolchain

2015-10-04T16:22:21+00:00

Our current ccache disables hashing of the compiler executable itself, because using the default 'mtime' doesn't work in buildroot: we always rebuild the compiler, so the mtime is always different, so the cache always misses. However, in the current situation, if a user changes the compiler configuration (which would result in the compiler generating different object files than before) and does 'make clean all', ccache may in fact reuse object files from the previous run. This rarely gives problems, because (1) the cache expires quite quickly (it's only 1GB by default), (2) radically changing compiler options will cause cache misses because different header files are used, (3) many compiler changes (e.g. changing -mtune) have little practical effect because the resulting code is usually still compatible, (4) we currently don't use CCACHE_BASEDIR, and almost all object files will contain an absolute path (e.g. in debug info), so when building in a different directory, most of it will miss, (5) we do mostly build test, and many of the potential problems only appear at runtime. Still, when ccache _does_ use the wrong cached object files, the effects are really weird and hard to debug. Also, we want reproducible builds and obviously the above makes builds non-reproducible. So we have a FAQ entry that warns against using ccache and tells the user to clear the cache in case of problems. Now that ccache is called from the toolchain wrapper, it is in fact possible to at least use the 'mtime' compiler hash for the external toolchain and for the host-gcc. Indeed, in this case, the compiler executable comes from a tarball so the mtime will be a good reference for its state. Therefore, the patch (sed script) that changes the default from 'mtime' to 'none' is removed. For the internal toolchain, we can do better by providing a hash of the relevant toolchain options. We are only interested in things that affect the compiler itself, because ccache also processes the header files and it doesn't look at libraries because it doesn't cache the link step, just compilation. Everything that affects the compiler itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of course, also the compiler source itself is relevant, so the source tarball and all the patches are included in the hash. For this purpose, a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced. The following procedure tests the ccache behaviour: Use this defconfig: BR2_arm=y BR2_CCACHE=y make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" Now make menuconfig, change variant into BR2_cortex_a9 make clean; make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" should be "Cortex-A9" After this commit, it is "Cortex-A9". Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Cc: Danomi Manchego Cc: Károly Kasza Cc: Samuel Martin Cc: Romain Naour Signed-off-by: Peter Korsgaard

toolchain-wrapper: support change of BR2_CCACHE

2015-10-04T16:22:20+00:00

By moving the ccache call to the toolchain wrapper, the following scenario no longer works: make foo-dirclean all BR2_CCACHE= That's a sometimes useful call to check if some failure is perhaps caused by ccache. We can enable this scenario again by exporting BR_NO_CCACHE when BR2_CCACHE is not set, and by handling this in the toolchain wrapper. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Tested-by: Romain Naour Reviewed-by: Romain Naour Signed-off-by: Peter Korsgaard

infra: move ccache handling to the toolchain wrapper

2015-10-04T16:22:20+00:00

Since we always have a toolchain wrapper now, we can move the ccache call to the toolchain wrapper. The hostcc ccache handling obviously stays. The global addition of ccache to TARGET_CC/CXX is removed, but many individual packages and infras still add it. This means we have a chain like this: ccache -> toolchain-wrapper -> ccache -> gcc However, this is fairly harmless: for cache misses, the inner ccache just adds overhead and for cache hits, the inner ccache is never called. Later patches will remove these redundant ccache calls. As a side effect, perl now supports ccache as well. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Cc: Danomi Manchego Cc: Károly Kasza Signed-off-by: Peter Korsgaard