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

arch/mips: add support for MIPS32 FP mode

2017-07-16T14:45:22+00:00

MIPS32 support different FP modes (32,xx,64), so give the user the opportunity to choose between them. That will cause host-gcc to be built using the --with-fp-32=[32|xx|64] configure option. Also the -mfp[32|xx|64] gcc option will be added to TARGET_CFLAGS and to the toolchain wrapper. FP mode option shouldn't be used for soft-float, so we add logic in the toolchain wrapper if -msoft-float is among the arguments in order to not append the -fp[[32|xx|64] option, otherwise the compilation may fail. Information about FP modes here: - https://sourceware.org/binutils/docs/as/MIPS-Options.html - https://dmz-portal.imgtec.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking#5._Generating_modeless_code Signed-off-by: Vicente Olivert Riera Signed-off-by: Thomas Petazzoni

arch/mips: add support for MIPS NaN

2017-07-16T14:35:39+00:00

MIPS supports two different NaN encodings, legacy and 2008. Information about MIPS NaN encodings can be found here: https://sourceware.org/binutils/docs/as/MIPS-NaN-Encodings.html NaN legacy is the only option available for R2 cores and older. NaN 2008 is the only option available for R6 cores. R5 cores can have either NaN legacy or NaN 2008, depending on the implementation. So, if the user selects a generic R5 target architecture variant, we show a choice menu with both options available. For well known R5 cores we directly select the NaN enconding they use. Signed-off-by: Vicente Olivert Riera Signed-off-by: Thomas Petazzoni

toolchain-wrapper: remove remaining references to HOST_DIR/usr

2017-07-10T15:46:11+00:00

Commit 14151d77af20ec50eeba6e30465debf87b35faaa that eliminated $(HOST_DIR)/usr seriously missed the toolchain-wrapper - only a single reference was updated, the other three were missed. Commit 015d68c84c9c6ad6f6d41f181d19d813f309088b removed one more. This commit finally removes the two remaining ones. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

toolchain-wrapper: fix breakage after host/usr removal

2017-07-07T07:57:14+00:00

The toolchain wrapper, when called through PATH, strips the last three levels of /proc/self/exe to find HOST_DIR. However, after the host/usr removal, this should be just two levels. The toolchain wrapper has different logic for when it is called with a full path (i.e. $HOST_DIR/usr/bin/arm-linux-gcc) then when it is called through the PATH (i.e. just arm-linux-gcc). The latter is never used internally in Buildroot, that's why this wasn't discovered through testing. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Cc: Mark Jackson Signed-off-by: Thomas Petazzoni

Eliminate $(HOST_DIR)/usr

2017-07-05T09:45:35+00:00

We currently use $(HOST_DIR)/usr as the prefix for host packages. That has a few disadvantages: - There are some things installed in $(HOST_DIR)/etc and $(HOST_DIR)/sbin, which is inconsistent. - To pack a buildroot-built toolchain into a tarball for use as an external toolchain, you have to pack output/host/usr instead of the more obvious output/host. - Because of the above, the internal toolchain wrapper breaks which forces us to work around it (call the actual toolchain executable directly). This is OK for us, but when used in another build system, that's a problem. - Paths are four characters longer. To allow us to gradually eliminate $(HOST_DIR)/usr while building packages, replace it with a symlink to . The symlinks from $(HOST_DIR)/usr/$(GNU_TARGET_NAME) and $(HOST_DIR)/usr/lib that were added previously are removed again. Note that the symlink creation will break when $(HOST_DIR)/usr already exists as a directory, i.e. when rebuilding in an existing output directory. This is necessary: if we don't break it now, the following commits (which remove the usr part from various variables) _will_ break it. At the same time as creating this symlink, we have to update the external toolchain wrapper and the external toolchain symlinks to go one directory less up. Indeed, $(HOST_DIR) is one level less up than it was before. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Reviewed-by: Romain Naour Signed-off-by: Thomas Petazzoni

Revert "reproducible: fix DATE/TIME macros in toolchain-wrapper"

2017-02-20T22:26:05+00:00

This reverts commit 76838f63412a30a358210e457dda4b79f7730624. The commit referenced above explicitly states that the function was copied as-is from the gcc source code at the time. And indeed that is exactly how the function appeared in gcc in commit e3e8c48c4a494d9da741c1c8ea6c4c0b7c4ff934. However, our toolchain wrapper is "GPLv2 only", while the file this function was copied from is "GPLv3 or later". As such we can't include that function and still comply to both licenses. Furthermore, the code is far from optimum. Since this feature is not release-critical, revert it until we re-implement it. Signed-off-by: "Yann E. MORIN" Cc: Jérôme Pouiller Cc: Samuel Martin Cc: Peter Korsgaard Cc: Thomas Petazzoni Cc: Arnout Vandecappelle Signed-off-by: Peter Korsgaard

reproducible: fix DATE/TIME macros in toolchain-wrapper

2017-02-07T20:45:01+00:00

The use of the __DATE__ and __TIME__ macros are one of the most common sources of non-reproducible binaries. In order to fix that, gcc 7 supports the SOURCE_DATE_EPOCH variable: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c8ea6c4c0b7c4ff934 This patch take advantage of toolchain-wrapper to provide support of SOURCE_DATE_EPOCH to older gcc versions. Function get_source_date_epoch() come directly from gcc git. This work was sponsored by `BA Robotic Systems'. [Peter: use sizeof for character array sizes, make function static, extend commit message, add upstream gcc commit] Signed-off-by: Jérôme Pouiller Reviewed-by: Samuel Martin Signed-off-by: Peter Korsgaard

toolchain/wrapper: use the {str, len} tuples for the unsafe paths

2016-12-11T14:45:06+00:00

In 61cb120 (toolchain/wrapper: extend paranoid check to -isystem), we introduced a {str,len} tuple to check the various arguments pased to gcc, to avoid hard-coding an ever-growing, long list of those args directly in the condition check. Now, we're left with a long list of unsafe paths, somehow hidden within the code, which can use the same mechanism we use for arguments. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Signed-off-by: Thomas Petazzoni

toolchain/wrapper: make the {str, len} tuple more generic, add comments

2016-12-11T14:44:44+00:00

In 61cb120 (toolchain/wrapper: extend paranoid check to -isystem), we introduced a {str,len} tuple to check the various arguments passed to gcc, to avoid hard-coding an ever-growing, long list of those args directly in the condition check. It was made specific to the arguments (the structure member is named 'arg'), but can also be used to store the unsafe paths as well. Also, that piece is almost un-documented. Rename the structure member so that it is more generic, and add a bit of comments to explain the whole of it. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Signed-off-by: Thomas Petazzoni

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