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
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:/
Hello,
the attached program changes the output from "true" to "false" when the
-Bsymbolic / -Bsymbolic-functions options are passed to GCC. This
happens on ARM -- on x86-64 output is always "true".
The program involves a comparison, within a shared library, of a PMF
defined inside the shared library itself with the same PMF passed by the
application.
At this stage I still don't know if it's a GCC problem, a ld.so problem,
ABI constraints, undefined behaviour, or whatnot; but any help is
appreciated.
Compile with:
> g++ -fPIC -shared -Wall -o libshared.so -Wl,-Bsymbolic shared.cpp
> g++ -fPIE -Wall -o main main.cpp -L. -lshared
(The long story is that Qt 5 is taking PMFs in its public API, and the
comparison failing inside of Qt shared libraries is breaking code on
ARM, as -Bsymbolic is set by default there.)
Thanks,
--
Giuseppe D'Angelo | giuseppe.dangelo(a)kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
This should match what we have in meta-linaro/dora, which is the linaro
2013.12 toolchain release.
---------- Forwarded message ----------
From: Koen Kooi <koen(a)dominion.thruhere.net>
Date: 17 January 2014 19:35
Subject: Fwd: seemingly bug in Linaro gcc 4.8
To: Koen Kooi <koen.kooi(a)linaro.org>
Begin doorgestuurd bericht:
> Van: Khem Raj <raj.khem(a)gmail.com>
> Onderwerp: seemingly bug in Linaro gcc 4.8
> Datum: 17 januari 2014 17:56:23 CET
> Aan: Koen Kooi <koen(a)dominion.thruhere.net>
>
> Hey Koen
>
> I am seeing a problem with linaro gcc-48 basically angstrom/2013.12
release
> The issue is attached sample C file. When compiled and run on my ArchLinux
> box which is running upstream gcc 4.8.2 it works ok
>
> but on beagleboard it fails.
>
>
> to compile
>
> $CXX -pthread -std=gnu++11 a.cpp
>
> on ARCH
>
> kraj@leo ~ > g++ b.cpp -std=gnu++11 -pthread
> kraj@leo ~ > ./a.out
> 140309495478016 i: 1
> 140309503870720 i: 2
>
> on Beagleboard
>
> root@beagleboard:~# ./std-thread
> pure virtual method called
> terminate called without an active exception
> Aborted
>
> Can you pass this to right folks in Linaro and get some help in resolving
it
>
> I havent yet trried it with OE-Core gcc which is also gcc 4.8
>
> The issue is most probably ARM related as it seems to me.
>
> Thanks for help
>
> -Khem
>
== This week ==
- Successfully submitted crypto using git-review
- Completed merge of ILP backports from trunk to Linaro 4.8 branch: 201164,
201165, 201166, 201167, 201168, 201170 and 201175
- Attended ARM architecture training on Friday
== Next week ==
- Submit ILP backports for review using git review
- New backports
== Future ==
== Progress ==
* Rework QEMU patch for AArch32 ARMv8 16<->64bit VCVT (2/10, TCWG-51)
* Further work on longjmp/setjmp Systemtap probes on ARM (4/10, TCWG-378)
* Research and analysis of malloc workloads for benchmarking (4/10, TCWG-160)
== Issues ==
* None
== Plan ==
* Finish testing setjmp/longjmp changes
* malloc benchmarking and improvements
--
Will Newton
Toolchain Working Group, Linaro
== Progress ==
* EHABI
- Turning EHABI on by default on non-Darwin ARM
- Had to add some relocations to MCJIT
- Re-enabled EH tests on test-suite
- Check-all, self-hosting and test-suite bots green
* Compiler-RT
- Enabling RT+San libraries to compile on ARM
- Changing Clang to look for the generic libraries (arm, not armv7l)
* MCJIT
- Remote protocol fixed, all tests passing on self-hosting bot
- All tests re-enabled on ARM
* Background
- More IAS, Compiler RT patch reviews
- Buildbot cleaning up before every build (more stable)
- Cambridge LLVM Social
- Rumours that LLVM can compile the kernel with the integrated assembler
on ARM
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* FOSDEM
- Talking about LLVM auto-vectorization this Sunday
* EHABI
- ARM detected some conflicts with Dwarf stack unwinding, investigate
Compiler-RT
- Run test-suite, benchmarks, applications with it
* IAS
- Confirm the rumours about the kernel compiling clean
- Pick up some remaining task to implement
I had a look at the missing target hook TARGET_ATOMIC_ASSIGN_EXPAND_FENV
to fix the C11 memory model testcase in regressions in trunk.
I looked at the x86 implementation of this target hooks and x86 has
instructions (FNSTENV,FLDENV,FNSTSW,FNCLEX) for feholdexcept,
feclearexcept and feupdateenv. Does ARM has something similar? Any
pointers/links I can refer to.
Please see the gcc internal documentation for the target hook below.
— Target Hook: void TARGET_ATOMIC_ASSIGN_EXPAND_FENV (tree *hold, tree
*clear, tree *update)
ISO C11 requires atomic compound assignments that may raise
floating-point exceptions to raise exceptions corresponding to the
arithmetic operation whose result was successfully stored in a
compare-and-exchange sequence. This requires code equivalent to calls to
feholdexcept, feclearexcept and feupdateenv to be generated at
appropriate points in the compare-and-exchange sequence. This hook
should set *hold to an expression equivalent to the call to
feholdexcept, *clear to an expression equivalent to the call to
feclearexcept and *update to an expression equivalent to the call to
feupdateenv. The three expressions are NULL_TREE on entry to the hook
and may be left as NULL_TREE if no code is required in a particular
place. The default implementation leaves all three expressions as
NULL_TREE. The __atomic_feraiseexcept function from libatomic may be of
use as part of the code generated in *update.
Thanks,
Kugan
== Progress ==
- releases (3/10)
* GCC 4.7 and 4.8 releases done
* more cbuild2 feedback
- cross-validations (2/10)
* followup
* adding capability to test a patch over a given revision on several
targets/cpu/fpu/runtestflags
- libsanitizer on AArch64 (3/10)
* most tests are now functional
* still some errors in the GCC testsuite, to be analyzed (there are
some timeouts, too despite using SSH multiplexing to the Foundation
model)
- misc (2/10): conf-calls and meetings
== Next ==
- libsanitizer on AArch64: analyze errors, try QEMU
== Future ==
On sick leave starting Feb 11th
== Progress ==
* Libc probes support for Aarch64 (2/10).
Wrote a small patch for setjmp and longjmp LIBC probe.
Requested "will newton" to test them .
* Investigate "PGO" for Aarch64 (3/10).
Bootstap testing GCC with PGO for GCC.
Stage 2, feedback profile in progress.
Ran coremark on foundation model with PGO.
The benchmark builds with profile-generate and runs.
"gcda" files are generated and uses them to profile.
Profile generated runs does not run cleanly.
Cross checking if the generated profile is valid.
* Resubmmited libssp machine description support in GCC (2/10).
* Cbuild2 discussed with rob, ryan on SYSROOT installation while building (1/10)
cross compiler for aarch64. "SYSROOT" is expected to be in
/opt/linaro, but cbuild2 does not do this by default.
Misc (1/10)
-------------
AMD internal meetings and did some investigations
== Plan ==
- Run EMBCC benchmarks with -PGO enabled.
- Follow up upstream libssp GCC discussions.
