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:/
Hi,
I'm trying to follow
https://wiki.linaro.org/WorkingGroups/ToolChain/Using/GCCNative but it
looks like it is outdated? Can someone confirm?
E.g.:
configure: WARNING: unrecognized options: --disable-bootstrap,
--with-mode, --with-arch, --with-tune, --with-fpu, --with-float
--
João M. S. Silva
== Progress ==
* Kernel (CARD-1246 2/8)
- Fixed edge cases for named registers
- http://llvm.org/PR19841
- http://llvm.org/PR19837
* Background (6/8)
- Code review, meetings, discussions, etc.
- TCWG Rack re-org
- Trying to set up native Chromebooks
- Trying to set up APM
- Trying to add Compiler-RT to our buildbots
== Plan ==
* Continue rack re-org
* Continue RT support on current bots
* Try libc++ bot
* Have a look at sanitizer bot
== Progress ==
* Bank Holiday Monday (2/10)
* Got a postgresql malloc benchmark running (4/10, TCWG-441)
* Started refactoring malloc microbenchmark based on review (2/10, TCWG-160)
* Patch review and testing (2/10)
== Issues ==
* None
== Plan ==
* Holiday Tuesday and Wednesday
* Finish refactoring malloc microbenchmark
* Work on results plotting code for benchmarks
--
Will Newton
Toolchain Working Group, Linaro
Hi,
I've been having this issue with latest binary Linaro 2014.04 toolchain from
http://releases.linaro.org/14.04/components/toolchain/binaries/gcc-linaro-a…
It comes with own sysroot, but linker fails to locate /lib/ld-linux-armhf.so.3
$ make
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o nvs.o nvs.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o misc_cmds.o misc_cmds.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o calibrator.o calibrator.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o plt.o plt.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o wl18xx_plt.o wl18xx_plt.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o ini.o ini.c
arm-linux-gnueabihf-gcc -L/tmp/lib/ nvs.o misc_cmds.o calibrator.o plt.o wl18xx_plt.o ini.o -lm -lnl-3 -lnl-genl-3 -o calibrator
/opt/linaro-2014.04/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/ld-linux-armhf.so.3
collect2: error: ld returned 1 exit status
Makefile:26: recipe for target 'all' failed
make: *** [all] Error 1
And when I pass my own sysroot, it works fine.
Is it supposed to work as a standalone toolchain with its own bundled sysroot?
Thanks.
--
Denys
I've been digging through test logs, and for gcc 4.9.1 native x86_64
tests, all the libsanitizer test cases fail to link due to unresolved
symbols from libpthread and libdl. Does anybody know more about this
bug, or care to fix it ? :-) It still exists in gcc trunk.
- rob -
== This week ==
- Completed GCC Launchpad bug dispositions [CARD-300][2/10]
- Backported PR61202 - gcc generated invalid sqdmulh instruction
[TCWG-485](2/10)
- Triaged and investigated Launchpad bug 1295738- Unable to find a
register to spill in class 'LO_REGS' [Card 300](3/10)
- Triaged and investigated Launchpad bug 1248752 - ARM assembly
instruction compile error [Card-300](3/10)
== Next week ==
- Resolve Launhpad bugs 1295738 and 1248752
- Triage and investigate other bugs as time warrants
== Future ==
No Plans.
== Planned holidays ==
No Plan
== Progress ==
* Worked on building binary tarballs from Jenkins. (TCWG 383 - 4/10)
* Continuing work on regression test analysis and reporting. (TCWG
448 - 3/10)
- now copying the check.log from make check to toolchain so
tcwgweb.sh can scan it for build errors in the test cases.
- Got the delimiter for concurrent Jenkins builds changed, now
glibc build problems are gone.
- Track down and try to fix testsuite build issues.
* Meetings and Misc. (3/10)
- Worked on making remote testing go faster. Setting
ControlPersist seems to help.
- Much debugging of Jenkins related issues.
== Plan ==
* Continuing work on validating test results and fixing testsuite
build issues. (TCWG 448)
* Probably more work on binary tarballs. (TCWG 383)
* More tracking down and fixing Jenkins related issues.
== Issues ==
* For some reason libgloss isn't getting built for *-elf via
Jenkins/Cbuildv2.
Hi,
I have tried out a prototype of using binfmt_misc, and it does not appear to be a worthwhile solution at this point.
Bottom line: with a nice fast multi-core x86 server and a pool of ARM boards we can test GCC in ~20min.
Testing setup:
- Core i3 2-core host
- Chromebook 2-core target, SSD disk
- WiFi network
- GCC mainline built from sources with same flags both natively and cross: C, C++, Fortran.
General observations about testing ARM toolchains:
- When testing natively target is busy 100%: around 50% of time is spent compiling testcases, 40-45% in dejagnu/expect, 5-10% on actual test execution. Target is the bottleneck.
-- 21633.22user 4400.13system 4:13:11elapsed
- With testing cross using standard rsh_prog=ssh, rcp_prog=scp, target is busy 40% of the time: 30% on ssh, 10% on actual test execution. Host is the bottleneck.
--
- When testing cross (using method below) target is busy only 15-20% of the time: 10% on ssh and 10% on actual test execution. Host is the bottleneck.
-- 9490.16user 2882.54system 1:10:57elapsed
I've got a prototype implementation of parallelized cross-testing of GCC that I'm happy with using rsh_prog and rcp_prog dejagnu wrappers:
General observations on dejagnu cross-testing process:
- All communication with the target is done by Dejagnu via rsh_prog and rcp_prog hooks. These are normally defined to ssh and scp respectively.
- Dejagnu copies every testcase to /tmp/ on the target with scp.
- Dejagnu executes every testcase via ssh off target's /tmp/. In total there is 1 scp and 3 ssh invocations per testcase.
The idea of below scripts is to assume shared filesystem between host and a pool of target boards, and skip copying executables to target's local filesystem. Since there is no longer local state (local state == contents of /tmp) on the target boards, testcases can be executed on any of the boards in the pool. This happens transparently to dejagnu: dejagnu issues "rsh_prog chromebook-pool ./test" and then rsh_prog converts this to "ssh chromebook-XX ./test", where XX chosen at random.
Script implementation notes:
- For some unholy reason there is no way of correctly parse command line from dejagnu and give it to bash. The reason why myssh script ssh'es onto host itself is because that's the only way I've found to reliably execute the command. Hey! The command line was intended for ssh anyway!
- Myssh script translates hostname of foobar-pool-01-03-08 into foobar01, foobar03 or foobar08 chosen at random. If there is no "-pool-" mentioned in hostname, then it is used verbatim.
--
Maxim Kuvyrkov
www.linaro.org