linaro-toolchain October 2014

linaro-toolchain@lists.linaro.org

26 participants
53 discussions

New IRC Channel for Linaro Toolchain Working Group

by Matthew Gretton-Dann

All, During Connect the suggestion was made that each working group should have its own IRC Channel for discussions and topics relating to the group in particular (as opposed to #linaro which is 'generic' Linaro conversations). Therefore I have just set up #linaro-tcwg on Freenode for the Toolchain Working Group. This channel is public and open to anyone who wants to talk with the TCWG group about anything toolchain related. Thanks, Matt -- Matthew Gretton-Dann Toolchain Working Group, Linaro

5 years, 3 months

[ANNOUNCE] Linaro Toolchain Binaries 2013.07 released

by Zhenqiang Chen

The Linaro Toolchain and Platform Working Groups are pleased to announce the 2013.07 release of the Linaro Toolchain Binaries, a pre-built version of Linaro GCC and Linaro GDB that runs on generic Linux or Windows and targets the glibc Linaro Evaluation Build. Uses include: * Cross compiling ARM applications from your laptop * Remote debugging * Build the Linux kernel for your board What's included: * Linaro GCC 4.8 2013.07-1 * Linaro Newlib 2.0 2013.06 * Linaro Binutils 2.23 2013.06 * Linaro Eglibc 2.17-2013.07-2 * Linaro GDB 7.6 2013.05 * A statically linked gdbserver * A system root * Manuals under share/doc/ The system root contains the basic header files and libraries to link your programs against. Interesting changes include: * The sysroot is based on Linaro versions of Eglibc. About details of Linaro Eglibc, please refer https://releases.linaro.org/13.07/components/toolchain/eglibc-linaro. The Linux version is supported on Ubuntu 10.04.3 and 12.04, Debian 6.0.2, Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation 5.7 and later, and should run on any Linux Standard Base 3.0 compatible distribution. Please see the README about running on x86_64 hosts. The Windows version is supported on Windows XP Pro SP3, Windows Vista Business SP2, and Windows 7 Pro SP1. The binaries and build scripts are available from: https://launchpad.net/linaro-toolchain-binaries/trunk/2013.07 Need help? Ask a question on https://ask.linaro.org/ Already on Launchpad? Submit a bug at https://bugs.launchpad.net/linaro-toolchain-binaries On IRC? See us on #linaro on Freenode. Other ways that you can contact us or get involved are listed at https://wiki.linaro.org/GettingInvolved. Know issues: * Some version information in README are incorrect. * gdb can not backtrace into libc. Notes: * To use all of the features of Linaro eglibc, the sysroot in 32-bit toolchain release is updated to Linaro eglibc, which is 2.17. If you get runtime errors about libc version, please get the sysroot from the release tarball (gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/arm-linux-gnueabihf/libc/) or download from launchpad https://launchpad.net/linaro-toolchain-binaries/support/01/+download/linaro… If you do not want to use Linaro sysroot, you'd add option to gcc to find your sysroot: --sysroot=<directory> * To run 32-bit application built from arm-linux-gnueabihf toolchain in aarch64 system, you'd copy sysroot and runtime from release package to your root of aarch64 system. i,e. scp -r gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/arm-linux-gnueabihf/libc/* AARCH64-SYSTEM:/ scp -r gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_runtime/* AARCH64-SYSTEM:/

11 years, 11 months

Separate out code used by a pager in OP-TEE

by Jens Wiklander

Hi toolchain champions, [please keep me in cc as I'm not subscribed to linaro-toolchain(a)lists.linaro.org] In OP-TEE we are going to activate a pager which is an integrated part of the statically linked secure OS binary (compiled for ARMv7/Aarch32 now, but at some point also Aarch64). The pager in OP-TEE allows use of more memory than the amount of available physical memory. This makes it possible to for instance have an OP-TEE binary that requires more memory than the amount of available memory. What the pager does is to map a physical page at the virtual address where the memory is needed and populate it which what is expected on demand. The pager also unmaps physical pages that hasn't been used in a while to be able to recycle it. The code used by the pager to map and populate a page must always be mapped since we would otherwise get a deadlock. The problem is that the pager is also part of OP-TEE so we need to partition the binary in a way that all code needed to handle a page fault is in one area in the binary and always mapped. Annotating functions and such as it's done in the Linux kernel with __init will not scale here since the pager will need routines from "third-party" libraries. We can make small changes to the libraries but identifying and annotating everything needed by the pager is too much. We would also run into troubles with strings. I have a couple ideas below that I need help exploring. What if we do an incremental linking of the entire TEE Core with garbage collect only keeping the entry functions of the pager? Then we would get an object file with everything the pager depends on included but not much more. It would be easy to put this single object file in a separate part of the OP-TEE binary. The procedure would be something like: Compile everything with -ffunction-sections -fdata-sections ld -i --gc-sections -u pager_entry -o pager_code.o $(objs) $(link-ldadd) $(libgcc) ld $(link-ldflags) pager_code.o $(objs) $(link-ldadd) $(libgcc) But the problem comes with linking in the rest of the code in the last step, we would get lots of multiple defined symbols. We could create a libtee_core.a file where we put all the $(objs) files and the linker would only use the needed object files. But we would still have some multiple defined symbols left since each .o file contains more than just one section. Any ideas how to solve this? We could perhaps split each .o file into several .o files each with only one section. Would it work? Would it make the resulting binary larger or inefficient? Another option could be to mark all symbols in libtee_core.a and other libaries as weak, but the problem here is that we already have some weak functions in TEE Core so this would break that. Perhaps if it would be possible to have different levels of weakness. Any ideas are welcome, either along this path or different approaches. Regards, Jens

11 years, 11 months

[RFC] Linaro release version number macros

by Yvan Roux

Hi, after the recent lkml thread on blacklisting some GCC versions (see below) and the issue in identifying accurately our releases, I propose to add some Linaro specific macros in our branches (i.e this patch will not go upstream) to be able to check the Linaro version at preprocessor time. It will not solve the kernel issue with 4.8.N but hopefully help if such issues happen again the the futur. http://thread.gmane.org/gmane.linux.ports.arm.omap/119412 What GCC has for the moment is 3 macros __GNUC__, __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ that are filled by parsing version number contained in BASE-VER file, for instance on our 4.9 branch: __GNUC__ = 4 __GNUC_MINOR__ = 9 __GNUC_PATCHLEVEL__ = 2 In our branches, the Linaro version number is in the LINARO-VERSION file and has this format: At release point : 4.9-2014.10 Head of our branch: 4.9-2014.10-1~dev I want your (the team and users) point of view on the macros we need to create from it. Here is the options I see: A - Be fully Linaro consistent: __LINARO_MAJOR__ = 4 __LINARO_MINOR__ = 9 __LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev B - Only give information that are not in the __GNUC* macros: __LINARO_YEAR__ = 2014 __LINARO_MONTH__ = 10 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev C - Be more concise: __LINARO_VERSION__ = 201410 __LINARO_SPIN__ = 0 or N __LINARO_STATE = 0 for release or 1 for dev D - Even more: __LINARO_VERSION__ = 201410N (with N the spin number) __LINARO_STATE = 0 for release or 1 for dev E - Hardcore conciseness: __LINARO__ = 201410NM (N = SPIN M = state) F - One of the previous ones without STATE information. G - One of the previous ones without SPIN information. Do you think it is something we need ? Do we already have that kind of macros in some products (binutils, gdb, glibc, ...) ? What option do you prefer ? My own feeling is that C+F is sufficient as STATE information is useless for releases and I don't think dev builds checking have to be used in another project. But SPIN information can be useful has we're doing respin because an outstanding issue/improvement has to be fixed/added to the current release, thus it is the kind of thing you want to check if the version of the compiler you are using contains. Thanks, Yvan

11 years, 12 months

Will this ARM64 erratum patch be backported to this month's Linaro GCC 4.9 release?

by Panshilin (Peter)

Dear all concerned: ARM has reported it's 53's bug:AArch64 multiply-accumulate instruction might produce incorrect result and developed the patch descriped below. will the patch be backported to Linaro 4.9 this month's release. https://gcc.gnu.org/ml/gcc-cvs/2014-10/msg00335.html thanks Peter

11 years, 12 months

[ACTIVITY] 27-31 October 2014

by Kugan

== Progress == * Zero/sign extension elimination with widening types (TCWG-546 - 10/10) - Fixed regression failures - Fixed bootstrapping issues for ARM and AArch64 - Re-factored and added some comments - x86-64 Bootstrapped and regression tested for all languages with forced promotion. There is 6 differences in scanning for certain instructions. All the execution tests are passing. Needs further investigation. == Plan == * Continue with Zero/sign extension pass. - Benchmarking - Get patch ready for upstream discussion * Improve block memory operations by GCC (TCWG-142) - Start work on this

12 years

[ACTIVITY] 27-31 October 2014

by Christophe Lyon

== Progress == * GCC trunk/4.9 cross-validation (1/10) - submitted a couple of patches to clean testsuite cases * Neon intrinsic tests (1/10) - submitted patch to avoid running the tests on ARM targets w/o Neon - started adding new tests - created 2 PR about intrinsic tests failing on AArch64_be (1 assigned to Venkat, 1 to me) * AArch64 sanitizer (1/10) - submitted a patch upstream to allow supporting both older and newer kernels No feedback so far. * GCC 4.8 and 4.9 releases (3/10) - preparing both releases including ARM's latest fixes for the A53 erratum - had to respin mid-week after new fix was committed - LINK_SPEC patch not committed yet in 4.8, and committed in 4.9 after I made the branch merge. - now checking results with references. Several FAIL appear. TBC. * cbuild2 schroot and master branches comparison (1/10) - re-ran schroot branch after cleaning spurious "-static" flag left in dejagnu configuration - better results, faster * Misc (3/10) - calls, meetings == Next == * GCC 4.8 and 4.9 releases: hopefully, after branch merge review * AArch64 sanitizer * Neon intrinsics tests update * cbuild2: - analyze previous results - look at backport-test and tcwgweb scripts + logs

12 years

[ACTIVITY] Week 44

by Renato Golin

== Progress == * US LLVM Dev Mtg (4/6) * Buildbots (TCWG-76 1/6) - Fixing last bugs of the libcxx bot - One last failure being looked at * Background (1/6) - Code review, meetings, discussions, etc. - Meeting with Google/ARM/Qualcomm about Android+LLVM * Two days off == Plan == * Investigate last libcxx bug * Move lab/office

12 years

Re: linaro-toolchain Digest, Vol 52, Issue 16

by 박주형

Thanks for the reply, Will Newton. Then can we expect the fix to be included for the official Android toolchain 2014.11? And, thanks for explaining the culprit of this bug, Jongsung Kim! :) On Wed, Oct 29, 2014 at 9:00 PM, <linaro-toolchain-request(a)lists.linaro.org> wrote: > Send linaro-toolchain mailing list submissions to > linaro-toolchain(a)lists.linaro.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.linaro.org/mailman/listinfo/linaro-toolchain > or, via email, send a message with subject or body 'help' to > linaro-toolchain-request(a)lists.linaro.org > > You can reach the person managing the list at > linaro-toolchain-owner(a)lists.linaro.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of linaro-toolchain digest..." > > > Today's Topics: > > 1. RE: Enabling back linker plugin for Linaro Android toolchain > (Jongsung Kim) > 2. Re: Enabling back linker plugin for Linaro Android toolchain > (Will Newton) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 29 Oct 2014 11:26:30 +0900 > From: "Jongsung Kim" <neidhard.kim(a)lge.com> > To: '???' <qkrwngud825(a)gmail.com>, <linaro-android(a)lists.linaro.org>, > <linaro-toolchain(a)lists.linaro.org> > Subject: RE: Enabling back linker plugin for Linaro Android toolchain > Message-ID: <012f01cff31f$c01cea90$4056bfb0$(a)lge.com> > Content-Type: text/plain; charset="UTF-8" > > The version-string from binutils-linaro looks to be blamed. It once was: > > GNU ld (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC > 2013.04) 2.23.1 > > and the linker plugin works with this version of Linaro prebuilt > toolchain. Now it is: > > GNU ld (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro GCC 4.8-2014.04) > 2.24.0.20140311 Linaro 2014.03 > GNU ld (crosstool-NG linaro-1.13.1-4.9-2014.08 - Linaro GCC 4.9-2014.08) > 2.24.0.20140801 Linaro 2014.08 > > and the linker plugin is not supported: > > $ arm-linux-gnueabihf-gcc -flto -fuse-linker-plugin -o hello hello.c > arm-linux-gnueabihf-gcc: error: -fuse-linker-plugin is not supported in > this configuration > > Look into gcc/configure script. It uses the version of ld to determine > whether ld supports linker plugin. It extracts the version by doing > something like: > > $ arm-linux-gnueabihf-ld --version | sed 1q | sed -n -e 's,^.*[ > ]$[0-9][0-9]*\.[0-9][0-9]*.*$$,\1,p' > > and it will extract the last 2014.03 or 2014.08. By using proper > substitution expression like 's,^GNU ld (.*) $[0-9][.0-9]*$.*$,\1,p', the > script may enable linker plugin. > > However, patching the script looks like a bad idea, because it doesn?t > help handling the version of gold: > > GNU gold (GNU Binutils for Ubuntu 2.24) 1.11 > GNU gold (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC > 2013.04 2.23.1) 1.11 > GNU gold (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro GCC 4.8-2014.04 > 2.24.0.20140311 Linaro 2014.03) 1.11 > GNU gold (crosstool-NG linaro-1.13.1-4.9-2014.08 - Linaro GCC 4.9-2014.08 > 2.24.0.20140801 Linaro 2014.08) 1.11 > > I couldn?t find a reasonable general expression to extract the version. > > > From: linaro-toolchain-bounces(a)lists.linaro.org [mailto: > linaro-toolchain-bounces(a)lists.linaro.org] On Behalf Of ??? > Sent: Monday, October 27, 2014 10:15 PM > To: linaro-android(a)lists.linaro.org; linaro-toolchain(a)lists.linaro.org > Subject: Enabling back linker plugin for Linaro Android toolchain > > I'm using Linaro Android toolchain's arm-eabi- for compiling my Android > Linux kernel with LTO. > > The main benefits of my kernel is that it uses > LTO(Link-Time-Optimizations). > (Patches found here: https://github.com/andikleen/linux-misc) > > But now, it's broken with Linaro Android toolchains from 2014.09~ > > Building Linux kernel with LTO requires Linker plugin with the toolchain. > > > But for some reason, linker plugin is disabled with 2014.09 and 2014.10 > (Which I used from here : > https://android-build.linaro.org/builds/~linaro-android/toolchain-4.9-2014.… > https://android-build.linaro.org/builds/~linaro-android/toolchain-4.9-2014.… > ) > > LTO build works flawlessly with 2014.08. > > With 2014.09 and 2014.10, I get the following error : > cc1: error: -fno-fat-lto-objects are supported only with linker plugin > > If I explicitly remove " -fno-fat-lto-objects " from the Makefile, the > linker fails to link all of the object files. > > > I would like to ask Linaro to enable back the Linker plugin support :) > > Thanks in advance.. > > > > > ------------------------------ > > Message: 2 > Date: Wed, 29 Oct 2014 09:12:53 +0000 > From: Will Newton <will.newton(a)linaro.org> > To: Jongsung Kim <neidhard.kim(a)lge.com> > Cc: ??? <qkrwngud825(a)gmail.com>, linaro-android(a)lists.linaro.org, > Linaro Toolchain <linaro-toolchain(a)lists.linaro.org> > Subject: Re: Enabling back linker plugin for Linaro Android toolchain > Message-ID: > <CANu=DmhPdCGYw0=hCs9tmkbCU6hMLLMJnYS-u_JGz= > p17Bgonw(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 29 October 2014 02:26, Jongsung Kim <neidhard.kim(a)lge.com> wrote: > > The version-string from binutils-linaro looks to be blamed. It once was: > > > > GNU ld (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC > 2013.04) 2.23.1 > > > > and the linker plugin works with this version of Linaro prebuilt > toolchain. Now it is: > > > > GNU ld (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro GCC 4.8-2014.04) > 2.24.0.20140311 Linaro 2014.03 > > GNU ld (crosstool-NG linaro-1.13.1-4.9-2014.08 - Linaro GCC 4.9-2014.08) > 2.24.0.20140801 Linaro 2014.08 > > > > and the linker plugin is not supported: > > > > $ arm-linux-gnueabihf-gcc -flto -fuse-linker-plugin -o hello hello.c > > arm-linux-gnueabihf-gcc: error: -fuse-linker-plugin is not supported in > this configuration > > > > Look into gcc/configure script. It uses the version of ld to determine > whether ld supports linker plugin. It extracts the version by doing > something like: > > > > $ arm-linux-gnueabihf-ld --version | sed 1q | sed -n -e 's,^.*[ > ]$[0-9][0-9]*\.[0-9][0-9]*.*$$,\1,p' > > > > and it will extract the last 2014.03 or 2014.08. By using proper > substitution expression like 's,^GNU ld (.*) $[0-9][.0-9]*$.*$,\1,p', the > script may enable linker plugin. > > > > However, patching the script looks like a bad idea, because it doesn?t > help handling the version of gold: > > > > GNU gold (GNU Binutils for Ubuntu 2.24) 1.11 > > GNU gold (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC > 2013.04 2.23.1) 1.11 > > GNU gold (crosstool-NG linaro-1.13.1-4.8-2014.04 - Linaro GCC > 4.8-2014.04 2.24.0.20140311 Linaro 2014.03) 1.11 > > GNU gold (crosstool-NG linaro-1.13.1-4.9-2014.08 - Linaro GCC > 4.9-2014.08 2.24.0.20140801 Linaro 2014.08) 1.11 > > > > I couldn?t find a reasonable general expression to extract the version. > > This should be fixed in binutils-linaro-2.24-2014.11. > > > From: linaro-toolchain-bounces(a)lists.linaro.org [mailto: > linaro-toolchain-bounces(a)lists.linaro.org] On Behalf Of ??? > > Sent: Monday, October 27, 2014 10:15 PM > > To: linaro-android(a)lists.linaro.org; linaro-toolchain(a)lists.linaro.org > > Subject: Enabling back linker plugin for Linaro Android toolchain > > > > I'm using Linaro Android toolchain's arm-eabi- for compiling my Android > Linux kernel with LTO. > > > > The main benefits of my kernel is that it uses > LTO(Link-Time-Optimizations). > > (Patches found here: https://github.com/andikleen/linux-misc) > > > > But now, it's broken with Linaro Android toolchains from 2014.09~ > > > > Building Linux kernel with LTO requires Linker plugin with the toolchain. > > > > > > But for some reason, linker plugin is disabled with 2014.09 and 2014.10 > > (Which I used from here : > https://android-build.linaro.org/builds/~linaro-android/toolchain-4.9-2014.… > https://android-build.linaro.org/builds/~linaro-android/toolchain-4.9-2014.… > ) > > > > LTO build works flawlessly with 2014.08. > > > > With 2014.09 and 2014.10, I get the following error : > > cc1: error: -fno-fat-lto-objects are supported only with linker plugin > > > > If I explicitly remove " -fno-fat-lto-objects " from the Makefile, the > linker fails to link all of the object files. > > > > > > I would like to ask Linaro to enable back the Linker plugin support :) > > > > Thanks in advance.. > > > > > > _______________________________________________ > > linaro-toolchain mailing list > > linaro-toolchain(a)lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/linaro-toolchain > > > > -- > Will Newton > Toolchain Working Group, Linaro > > > > ------------------------------ > > _______________________________________________ > linaro-toolchain mailing list > linaro-toolchain(a)lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-toolchain > > > End of linaro-toolchain Digest, Vol 52, Issue 16 > ************************************************ >

12 years

Enabling back linker plugin for Linaro Android toolchain

by 박주형

I'm using Linaro Android toolchain's arm-eabi- for compiling my Android Linux kernel with LTO. The main benefits of my kernel is that it uses LTO(Link-Time-Optimizations). (Patches found here: https://github.com/andikleen/linux-misc) But now, it's broken with Linaro Android toolchains from 2014.09~ Building Linux kernel with LTO requires Linker plugin with the toolchain. But for some reason, linker plugin is disabled with 2014.09 and 2014.10 (Which I used from here : https://android-build.linaro.org/builds/~linaro-android/toolchain-4.9-2014.… https://android-build.linaro.org/builds/~linaro-android/toolchain-4.9-2014.… ) LTO build works flawlessly with 2014.08. With 2014.09 and 2014.10, I get the following error : cc1: error: -fno-fat-lto-objects are supported only with linker plugin If I explicitly remove " -fno-fat-lto-objects " from the Makefile, the linker fails to link all of the object files. I would like to ask Linaro to enable back the Linker plugin support :) Thanks in advance..

12 years

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain October 2014