Folks,
Me and Nick have been back and forth with the IFC6410, using Linaro's
utopic Ubuntu + 3.17 kernel, and I can now declare it stable enough to
run toolchain tests, maybe not yet builds.
The reason is that the kernel, although stable, is only just because
it throttles speed to a minimum. So, the core runs at 920MHz and the
memory bus is at its minimum frequency. Nick gathers we could speed it
up by a factor of 30% and 40% respectively while remaining on the
safety zone.
However, that would still be not enough. Currently, the boards build
LLVM in 7hs, when a Panda does it in 5h, a Chromebook does in 3.5hs
and a Chrome2 in 2hs. Improving it by 85% would get us just under 4hs,
which is still worse than a Chromebook. If we increase the CPU clock
to 1.5GHz per core, we may get it fast enough (but still slower than
the Chrome2), to be useful.
Their form-factor are better for rack-usage (remote serial, remote
reboot, small footprint), so even being slower than Chrome 2s, they'll
be faster than Chrome 1s and much more rack-friendly. That, of course,
assuming they remain stable at 1.5GHz. Heating will be an issue, but
we now have a decent server room and we can buy rack-mounted fans for
them, if we need it.
In a nutshell, I won't give up on them just yet, but I won't speed up
replacing the other boards with them either. We may have to wait a few
more releases to be sure, but I'm not expecting anything going in
production before February.
cheers,
--renato
PS: Nick, if you want to increase the clock speeds now just to see
what happens, I'm game.
Hi,
The latest toolchain on the following page appears to be broken.
http://www.linaro.org/projects/armv8/
Looking around one comes across the following path.
http://releases.linaro.org/latest/components/toolchain/.binaries
However the tarballs there yield: "You do not have permission to access this
file."
Thanks,
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
== Progress ==
QEMU kernel debugging setup [5/10] [TCWG-568]
-- Setup arm Linux kernel debugging to debug watchpoints
GDB with cygwin build/testing process [2/10]
-- Figured out GDB build and test procedure on cygwin.
Miscellaneous [3/10]
-- Meetings, Emails etc
-- Hong Kong visa application: re-submission of application.
== Plan ==
QEMU kernel debugging setup [TCWG-568]
-- Try to figure out kernel debugging help for ptrace debug
GDB with cygwin build/testing process
-- Document cygwin gdb work flow
-- Buid arm-remote gdb on cygwin
-- Identify gdb-remote issues on a cygwin host if any
== This week ==
* GCC modularization project
- Fixed df.h flattening patch to build on all targets in config-list.mk
- Flattening expr.h patch in progress.
== Next week ==
- complete expr.h patch
- Submit df.h flattening patch to gcc-patches for review
- Test cfgloop.h flattening patch on all targets with ISL enabledin
config-list.mk and submit to gcc-patches for review.
Holiday [6/10]
Misc [3/10]
* Mail backlog
* Moved all current AArch64 work off 'my' Juno, as ARM needed it back
* A little bit of a look at another possible memcpy performance issue
libm exercising - TCWG-558 [1/10]
* Reduced 'needless calls to pow' to a simple test case
** Found that this is actually an all-targets thing (at least AArch32,
AArch64, x86)
* Looked through benchfft output
** Looks like only one implementation calls libm much
** This is probably just bad code, but could do with a comparison run
on non-AArch64 to be sure
=Plan=
Switch to TCWG Junos
Think about where to go next with libm exercising
Complete 'same network' workaround, test benchmark repeatability
Port benchmarking scripts to ABE repo
Get storage/automation started, if Rob has time
=Absences=
On holiday Monday 22nd Dec to Friday 2nd Jan
== Progress ==
Bug#403/#418/PR63870 [7/10]
. Prepared patches for vldN_lane/vstN_lane
. reviewed related patches on list
. code changes are ready, but reveal errors in the testsuite
Misc [3/10]
. mailing llists
. meetings
. some help with lab config with Renato
= Progress ==
* TSAN support for Aarch64 (6/10)
* Emails, linaro/AMD status meetings. (4/10)
1-1 with maxim, Christophe.
== Plan ==
* TSAN support for Aarch64.
* Fix Linaro Bug 863
== This week ==
* GCC Modularization Project (9/10)
- Flattening header files
- tree-core.h, and tree.h, c-common.h
- Completed
- Bootstrap successful on x86
- Testing in progress on all platforms listed in config-list.mk
- Reviewed and tested patches from Prathamesh
* Misc (1/10)
- Conference calls
== Next week ==
- Submit tree.h and related patches for review
Hi all,
I've asked ITS to install a git post-commit hook to send an email
after commits in the toolchain git repos.
It turns out that they prefer to send such email to mailing-lists, to
avoid having to maintain the list of recipients themselves, which of
course really makes sense.
So far, we already have a cbuild2 mailing-list for commits, which Rob
asked to now point to abe instead of cbuild2 repo.
I was thinking about asking a single new mailing-list (eg
tcwg-commits) and send commit emails to that list for all ours repos,
instead of having a list per repo to which interested team members
would have to subscribe.
We currently have the following git repos:
abe
backflip
backport-tools
binutils-gdb
binutils
cbuild2
cortex-malloc
cortex-strings
cross-build-tools
dejagnu
dmucs
eglibc
fakebench
gcc-new
gcc
gdb
glibc
lavabench
newlib
release-notes
spec2xxx-utils
tcwg-sysadmin
Any objection to having such a list?
(I do not plan to force subscription of any of you :-)
Christophe.
== Progress ==
* Automation Framework (CARD-1378 5/8)
- Re-adding Junos and D01s to the rack
- Planning access from remote servers
- Following up new rack setup
- Moving lab bridge to a VM
- Re-checking all boards for stability
- Working on the dragon boards to get them stable
* Background (3/8)
- Code review, meetings, discussions, etc.
- Trying to get the LLVM Perf system back online
- Multiple bot breakages
- Reviewing patches for 3.5.1 release
- Jira farming
* 1 day off
== Plan ==
* Continue working on the dragon boards
* Try to get an internal ARM64 buildbot
* Hopefully finish off the lab move
== Progress ==
* GCC trunk/4.9 monitoring (2/10)
- still tracking cause of random "interrupted system call" errors
- checked possible regressions
* AArch64 sanitizers (1/10)
- managed to build on board, didn't try to run the tests yet
* Neon intrinsics tests (2/10)
- fixed a couple of bugs in the already upstreamed tests
- continued conversion to GCC testsuite
- support to external user (LLVM based compiler)
* 4.9-2014.12 release (1/10)
- backports+branch reviews
* Misc (4/10)
- meetings, conf-calls, emails....
== Next ==
* GCC trunk/4.9 monitoring
* AArch64 sanitizers
* Neon intrinsics tests
* cbuild2/abe: look at backport and tcwgweb
Holidays: Dec 22nd - Jan 2nd
Apology for sending this out late.
== Progress ==
Debugging ARM gdb watchpoint failures [4/10] [TCWG-567]
-- Prepared a testsuite patch for unsupported tests on ARM
-- Investigation of other failures due to watchpoints installation
rejected through ptrace interface.
QEMU kernel debugging setup [4/10] [TCWG-568]
-- Setup arm Linux kernel debugging to debug watchpoints
Studying arm debug unit architecture versions for possible upgrade to
watchpoint/hwbreak implementation. [1/5] [TCWG-569]
Miscellaneous [1/10]
-- Meetings, Emails etc
-- Follow up on Hong Kong Visa
== Plan ==
Figure out unexplained arm gdb watchpoint rejection from ptrace interface.
More work to figure out a way to debug arm Linux kernel using QEMU
Some further study on arm debug unit architecture versions.
== Progress ==
Holiday [1/10]
Investigated bug #928 [4/10]
. turns out to be invalid implementation of memset in old linux kernels
. raises a question - do we want to provide support for users of old
Linux kernels on new compilers? We could spend a long time rehashing
work the kernel community has already done.
bugs #403/418 [3/10]
. working on fixing error reporting for Aarch64 vldN_lane/vstN_lane
. trickier than expected, but have found a plan to implement this week
Misc [2/10]
== Plan ==
submit patch for #403/418 vldN_lane and work on more intrinsics
== Issues ==
* Validation unusable all week, seems to be operational now.
== Progress ==
* GCC 4.9 2014.12 (5/10)
- Struggle with backports validation,
- everything is in the pipe now ... wait and see
* Misc: (5/10)
- Scripted the GCC revisions management, now able
to track ARM related trunk contribution and fill the backport
spreadsheet, and will be able to generate the release notes.
- Various meetings.
== Plan ==
* Backports
* Branch merge
* Libunwind (AArch64_be review)
Back from Vacation 24, 26, 27 and 28 November. (8/10)
= Progress ==
* TSAN support for Aarch64 (1/10)
* Emails, linaro and AMD status meetings. (1/10)
1-1 with maxim
== Plan ==
* TSAN support for Aarch64.
* Fix Linaro Bug 863
* catchup emails and other discussions
== This week ==
* GCC Modularization Project
- created initial patch for flattening cfgloop.h.
- created initial patch for flattening df.h.
== Next Week ==
- Finalizing patches for cfgloop.h and df.h.
- Continue working on flattening header files.
== Progress ==
* Zero/sign extension elimination with widening types (1/10)
- Addressing comments from the review
* BUG #398 #412 (5/10)
- built kernel revision with provided config and toolchain binary
release to reproduce gcc segafult. Couldn’t reproduce it. Since there
is no more details to reproduce, closed it as cant reproduce.
- Spec2k gcc optimization issue was reproduced and reduced test-case
was created.
- dumps shows that this issue could be related to splitting constants
for early during expand might be the root cause.
* Holiday (4/10)
== Plan ==
* Continue with Zero/sign extension.
* BUG #412
== Planned Leave ==
* 11/12/2014 to 24/12/2014 - 10 days
== Progress ==
* 2 days sick
* Lab move (2/6)
* Buildbots (TCWG-76 2/6)
- Created a buildmaster at Linaro to help local development
- Put a dragonboard as a slave, which lasted 2 days up
* Background (2/6)
- Code review, meetings, discussions, etc.
== Plan ==
* I have no idea
== Progress ==
* Building an ILP32 toolchain for AArch64 (3/10, TCWG-559)
- More work on tidying patches
- Trying to get a test environment for ILP32
* LLD for ARM and AArch64 (5/10)
- Submit more reloc cleanups for LLVM
- Patch review
- Reading code
* glibc patch review (1/10, CARD-341)
* Email, meetings, etc. (1/10)
== Issues ==
* OE on Junos no good for building toolchains
* Ubuntu on Junos still seems vaporware
* Running out of disk space on development machine (bought an external HD)
== Plan ==
* More work on LLD
* Try QEMU for ILP32 work
--
Will Newton
Toolchain Working Group, Linaro
ABE benchmarking - TCWG-360 [4/10]
* Implemented most of a solution to the 'must be in same network' restriction
libm exercising - TCWG-558 [4/10]
* lulesh generates needless calls to pow on AArch64 (as opposed to
'pow is slow')
** Working on a reduced test case
* Ran a chunk of benchfft, left a process searching the perf reports
for libm calls
* More chroot/glibc fiddling
* Decided Graph500 was unlikely to be interesting
Misc - [2/10]
=Plan=
On holiday Monday - Wednesday
More lulesh, benchfft results
Think about where to go next with libm exercising
Complete 'same network' workaround, test benchmark repeatability
Port benchmarking scripts to ABE repo
Get storage/automation started, if Rob has time
Hi All,
Currently linaro toolchain for arm-linux-gnueabihf built with crosstool-ng scripts uses prebuilt sysroot.
I am trying to build eglibc on my own without using prebuilt sysroot. I am not able to exactly create same layout in the library layout.
Linaro build layout looks:
gcc-linaro-arm-linux-gnueabihf-4.8-2014.01_linux\arm-linux-gnueabihf\libc\usr\lib --> arm-linux-gnueabi arm-linux-gnueabihf
one for soft float and other for hard float fp. Can anybody please tell how we tell build system to create directories like above while building eglibc?
I used following commands to build eglibc:
../src_eglibc/configure --disable-profile --without-gd --without-cvs --prefix=/usr libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes --with-headers=<some_dir>/arm-linux-gnueabihf/libc/usr/include --host=arm-linux-gnueabihf
Make all
make install install_root= <some_dir>/arm-linux-gnueabihf/libc/
Thank you very much for your help.
//Mallikarjuna
Forwarding this message to the linaro toolchain list instead. I am not the person who should be supporting the Linaro ODP project with GCC questiosn; the toolchain team inside Linaro should be instead.
Thanks,
Andrew Pinski
________________________________________
From: Ola Liljedahl <ola.liljedahl(a)linaro.org>
Sent: Monday, November 24, 2014 2:31 PM
To: lng-odp(a)lists.linaro.org; Pinski, Andrew
Subject: strange behavior in GCC for use of uninitialized variables
Consider the following code fragment (from real life):
#include <stdint.h>
typedef volatile uint32_t odp_atomic_u32_t;
static inline uint32_t odp_atomic_fetch_inc_u32(odp_atomic_u32_t *ptr)
{
return __sync_fetch_and_add(ptr, 1);
}
static inline void odp_spin(void)
{
#ifdef __SSE2__
__asm__ __volatile__ ("pause");
#else
__asm__ __volatile__ ("rep; nop");
#endif
}
typedef struct {
int count;
odp_atomic_u32_t bar;
} odp_barrier_t;
void odp_barrier_wait(odp_barrier_t *barrier)
{
uint32_t count;
int wasless;
// wasless = barrier->bar < barrier->count; <<<lost on git add -p
__atomic_thread_fence(__ATOMIC_SEQ_CST);
count = odp_atomic_fetch_inc_u32(&barrier->bar);
if (count == 2*barrier->count-1) {
barrier->bar = 0;
} else {
while ((barrier->bar < barrier->count) == wasless)
odp_spin();
}
__atomic_thread_fence(__ATOMIC_SEQ_CST);
}
While fixing and cleaning up this code, the indicated line that
initializes 'wasless' was dropped (because it reappears in a later
patch in the patch set after the odp_atomic_fetch_inc call). To my
surprise, GCC did not complain when compiling this file (using -O2
-Wall). But it does complain when compiling with -O0 -Wall. With some
investigation, it seems like GCC understands that if a statement does
not have any side effects so it can optimize away everything,
including the usage of the uninitialized variable and thus also the
corresponding warning.
olli@macmini:~/hacking/gcc-wunit$ gcc -O2 -Wall -c odp_barrier.c
olli@macmini:~/hacking/gcc-wunit$ gcc -O0 -Wall -c odp_barrier.c
odp_barrier.c: In function ‘odp_barrier_wait’:
odp_barrier.c:42:9: warning: ‘wasless’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
while ((barrier->bar < barrier->count) == wasless)
^
However the proper code seems to be generated in both cases (there is
a "pause" instruction inlined or a call to odp_spin). So odp_spin() is
not without side effects and is not optimized away. This contradicts
my hypothesis.
Consider this minimalistic example:
olli@macmini:~/hacking/gcc-wunit$ cat wunit.c
#include <stdlib.h>
void test(void)
{
int wasless;
int wasmore;
if (wasless) (void)0;
if (wasmore) abort();
}
olli@macmini:~/hacking/gcc-wunit$ gcc -O0 -Wall -c wunit.c
wunit.c: In function ‘test’:
wunit.c:9:5: warning: ‘wasmore’ is used uninitialized in this function
[-Wuninitialized]
if (wasmore) abort();
^
olli@macmini:~/hacking/gcc-wunit$ gcc -O2 -Wall -c wunit.c
wunit.c: In function ‘test’:
wunit.c:9:5: warning: ‘wasmore’ is used uninitialized in this function
[-Wuninitialized]
if (wasmore) abort();
^
Here GCC warns when used with both -O0 and -O2 but only for the usage
where there is a side effect. The use of 'wasless' that does not lead
to any side-effects is ignored (and possibly rightly so, I can imagine
this is undefined behavior, fortunately I did not attempt to run this
program or my computer could have melted).
It is a bit worrying to me that instances of use of initialized
variables is sometimes missed by GCC. Both because of lack of
diagnostics for what is most likely a bug but also because I don't
understand why GCC does this and the implications of that (at least it
is a known unknown now).
-- Ola
cbuild2/ABE benchmarking - TCWG-360 [1/10]
* Attempted to use LAVA for benchmarks
** Fell over on lack of TCWG machines in same network
libm exercising - TCWG-558 [6/10]
* Much fiddling with chroots
* Some fiddling with benchfft
* Little actual progress
Meetings/mail/etc - [3/10]
=Plan=
libm exercising
* Run benchfft in chroots
* Investigate Graph500
* Validate existing results with consistent methodology
** Hopefully this is reaching the point of handle-turning
ABE benchmarking
* Port 'cbuild2' benchmarking to ABE repository
* Test ABE benchmarking in TCWG lab (and LAVA?)
* Test repeatability (assuming the above go well)
* Get storage/automation started, if Rob has time
Holiday *next* week (Tuesday and Wednesday, perhaps Monday as well)
== Progress ==
* Building an ILP32 toolchain for AArch64 (4/10, TCWG-559)
- Applied a few simple ILP32 patches to glibc
- Rebasing and reworking existing ILP32 glibc patches
* LLD for ARM and AArch64 (5/10)
- Submit first set of reloc cleanups for LLVM
* Email, meetings, etc. (1/10)
== Issues ==
* None
== Plan ==
* Submit more ILP32 patches for glibc
* Further LLVM/LLD changes
--
Will Newton
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:/
== Issues ==
* none.
== Progress ==
* GCC 4.9 2014.12 (2/10)
- Back on Backports.
- Around 30 revisions backported are under review.
* AArch64 libunwind/ptrace (6/10)
- Remote unwinding is not working because of a wrong ptrace invocation.
- Implement registers access with PTRACE_GETREGSET
* Misc: (2/10)
- GCC git mirror migration.
- Various meetings.
== Plan ==
* Backports
* Libunwind
== This week ==
* GCC Modularization Project (7/10)
- Flattening header files
- Submitted gimple-streamer.h, tree-streamer.h, lto-streamer.h
patches to gcc-patches list
- tree-core.h
- Several rounds of changes based on review and bootstraps
- final fifty target bootstrap in progress
- df.h
- Initial round of changes
- cfgloop.h
- Initial patch created by Parthamesh
* Bug fixing (2/10)
- Investigation of bug 539 - .LTHUNK symbols are surviving
* Misc (1/10)
- Conference calls
- Worked with Prathamesh to bootstrap him on GCC modularization project
== Next week ==
- Submit tree-core.h patches
- Complete df.h pathces
- Review Prathamesh's patches to cfgloop.h
- Thanksgiving holiday, November 27-28
== Progress ==
* Zero/sign extension elimination with widening types (2/10)
- Addressing comments from the review
* Improve block memory operations by GCC (TCWG-142 - 3/10)
-Looked at ARM vs AArch64
* BUG #880 (3/10)
- Analysed tree dumps.
- Updated bug report with the findings.
* MISC (2/10)
- Looked at git and stg documents
== Plan ==
* Continue with Zero/sign extension.
== Planned Leave ==
* 27/11/2014 to 28/11/2014 - 2 days
* 11/12/2014 to 24/12/2014 - 10 days
== Progress ==
Environment setup, installations, board setup etc [4/10]
-- Prepared a local dev machine to work with in absence of lab.
-- Prepare panda board for gdb on android testing.
-- Figure out SSH failure issues with gdb testsuite runs.
-- Try out foundation model for android testing.
-- Getting to know CBuildv2 tried to set it up locally.
On travel to submit Hong Kong visa application [5/10]
Miscellaneous [1/10]
-- Meetings, Emails etc
== Plan ==
Try android boot with foundation model some more and hope that it works.
Resume AArch64 work with lab availability.
Review and update GDB related cards.
== Progress ==
bug #403/418 [5/10]
. submitted partial patch to list for core fix for Aarch64
. needs reworking of expansion for a bunch of builtins + corresponding patterns
. discussion/review of related upstream patches
bug #868 - brief investigation [1/10]
Misc [4/10]
== Plan ==
On holiday on Friday and following Monday morning
1 day off (2/10)
== Issues ==
* none.
== Progress ==
* GCC 4.9 and 4.8 2014.11 (6/10)
- Backported ILP32 related commits in 4.9
- Validate and committed Linaro release macros in Linaro branches.
- Released 4.9 and 4.8 2014.11
* Lab move (1/10)
- Tested new validation infrastructure.
* Misc: (1/10)
- Finished libunwind task
- Various meetings.
== Plan ==
* Back on backports
cbuild2 benchmarking - TCWG-360 [5/10]
* Fixed some bugs and did some general tidying up
* Pulled SPEC2000 into my framework
* Did some test runs on local machines, looks promising
libm exercising - TCWG-558 [3/10]
* Much fiddling with one benchmark (MCB)
* Experimented, thought about methodology
Meetings/mail/etc - [2/10]
=Plan=
cbuild2 benchmarking
* Tweak eembc - it worked before, but spec forced me to change the
scripts a little
* Test in LAVA/new TCWG infrastructure when available
* Test repeatability (depends on above)
* Possibly have another go at building tools on AArch64
libm exerising
* Work through the most interesting benchmarks with a fixed method
* Hopefully reach the end and do some analysis
= Progress ==
* TSAN support for Aarch64 (4/10)
* Fix Linaro Bug 863,869 - reproduced them. Working on fixing 863 (1/10)
* Misc [3/10]
Emails, linaro and AMD status meetings.
1-1 with inline mangers (Mev, Ryan).
1-1 with christophe.
* 11/11/2014 Leave (2/10)
The task on "Debug and understand the inline differences trunk vs linaro
compiler for core mark at -O3 with LTO + PGO" is on hold now.
== Plan ==
* TSAN support for Aarch64.
* Fix Linaro Bug 863
* AMD internal event on 17/11/2014.
== Progress ==
* Zero/sign extension elimination with widening types (5/10)
- Addressing comments from the review
* Improve block memory operations by GCC (TCWG-142 - 5/10)
- Looked at gcc/glibc implementations
- Experimented with x86_64 vs ARM and found different implementation
decisions
- Discussed work items
== Plan ==
* Continue with improve block memory operations by GCC.
* Continue with Zero/sign extension.
== Progress ==
* Building an ILP32 toolchain for AArch64 (5/10, TCWG-559)
* Investigate ARM port of lld (3/10)
* Email, meetings, etc. (2/10)
== Issues ==
* None
== Plan ==
* Further work on ILP32 toolchain
* LLD
--
Will Newton
Toolchain Working Group, Linaro
1 day off (2/10)
== Progress ==
* Linaro GCC 4.8
- updated branch merge, to include the latest errata-related backport
- added Michael's backport for bug #534.
* GCC trunk/4.9 cross-validation (2/10)
- updated vbic/vorn tests patch
- trying to track down cause of spurious 'interrupted system call'
errors in the ST Compute Farm
* AArch64 sanitizer (1/10)
- After discussing with Arnd, the kernel patch causing trouble to
libsanitizer should also be backported to stable kernel branches. This
makes a compiler test based on kernel version impracticable.
- Shared this feedback with sanitizer maintainers, got no feedback.
- libsanitizer maintainers have updated GCC's snapshot with a more
recent version:
- GCC trunk now requires updated kernel headers for aarch64
- reported regressions when the compiler generates Thumb code
(incomplete backtrace)
* Neon intrinsics tests (2/10)
- submitted a series of 9 new tests.
- looking at vldX bugs on aarch64_be, along with ARM's incomplete patches.
* cbuild2
- no progress
* Misc (3/10)
- calls, meetings, support
== Next ==
* AArch64 sanitizers
* Neon intrinsics
* cbuild2 (improve backport-test and tcwgweb)
The Linaro Toolchain Working Group (TCWG) is pleased to announce the 2014.11
stable release of both Linaro GCC 4.9 and Linaro GCC 4.8 source packages.
With the imminent release of ARMv8 hardware and the recent release of the
GCC 4.9 compiler the Linaro TCWG will be focusing on stabilization and
performance of the compiler as the FSF GCC compiler. The Linaro TCWG provides
stable[1] quarterly releases and monthly engineering[2] releases.
Linaro GCC 4.9 2014.11 is the eighth Linaro GCC source package release and
second stable one in the 4.9 series. It is based on FSF GCC4.9.3-pre+svn216979
and includes performance improvements and bug fixes.
Interesting changes in this GCC source package release include:
* Updates to GCC 4.9.3-pre+svn216979
* Backport of [AArch64] Fix ILP32 ld.so
* Add new Linaro release macros : __LINARO_RELEASE__ and __LINARO_SPIN__
Linaro GCC 4.8 2014.11 is the fifteenth release in the 4.8 series and second
one since entering maintenance. Based off the latest GCC 4.8.4-pre+svn217270
release, it includes performance improvements and bug fixes.
Interesting changes in this GCC source package release include:
* Linaro bugzilla PR fixed : #307, #534
* Updates to GCC 4.8.4-pre+svn217270
* Add new Linaro release macros : __LINARO_RELEASE__ and __LINARO_SPIN__
Feedback and Support
Subscribe to the important Linaro mailing lists and join our IRC channels to
stay on top of Linaro development.
** Linaro Toolchain Development "mailing list":
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
** Linaro Toolchain IRC channel on irc.freenode.net at @#linaro-tcwg@
* Bug reports should be filed in bugzilla against GCC product:
http://bugs.linaro.org/enter_bug.cgi?product=GCC
* Questions? "ask Linaro":
http://ask.linaro.org/.
* Interested in commercial support? inquire at "Linaro support":mailto:
support(a)linaro.org
[1] Stable source package releases are defined as releases where the full Linaro
Toolchain validation plan is executed.
[2] Engineering source package releases are defined as releases where the
compiler is only put through unit-testing and full validation is not
performed.
Hello,
We have implemented gdb server in one of our project and we are using Linaro aarch64-none-elf-gdb.exe as gdb client. Our gdb server will response to packet 'qXfer:features:read:target.xml:0,fff' with a xml file which only claims feature 'org.gnu.gdb.aarch64.core'. However, when I issue 'info reg' command with the gdb client, it actually sends out a packet '$p42#d6', which is trying to read fpsr if I understand correctly. Is this an expected behavior or not? I just want to figure out whether our gdb server send some bad info to the gdb client and made the client thinks FP registers are valid. I hope I made my question clear and I'm really appreciate if anybody can help us on this again.
Thanks,
Strong
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
== Progress ==
AArch64 work on tracepoints and watchpoints failures [4/10]
-- Review of AArch64 debug hardware architecture
-- AArch64 debugging/testing stalled due to lab down time
-- Tried compiling and running custom AArch64 kernel with foundation model
Work on some arm specific fix of reverse-step and reverse-finish
commands. [TCWG-498] [1/10]
Miscellaneous [1/10]
-- Meetings, Emails etc
-- Prepared Hong Kong visa documents
-- Annual Review 2014
Public Holidays [4/10]
== Plan ==
Complete documents and travel to Islamabad for Hong Kong visa
Resume AArch64 work on tracepoints and watchpoints failures with lab
availability.
== Progress ==
* Pushed malloc microbenchmark to glibc (1/10, TCWG-160)
* Upstream work (4/10, CARD-341)
- glibc patch review (C11 atomics series)
- glibc patchwork cleanup
* Look into binutils input fuzzing fixes (1/10)
* Investigate ARM port of lld (2/10)
* Email, meetings, review, etc. (2/10)
== Issues ==
* Installed new cable modem. Seems to be working...
== Plan ==
* Plan toolchain ILP32 work
* lld investigation
--
Will Newton
Toolchain Working Group, Linaro
cbuild2 benchmarking - TCWG-360 [4/10]
* SPEC 2006 cross-built binaries now running. Easy when you know how.
libm exercising - CARD-1693 [4/10]
* Understood improved libm usage on 1 benchmark.
* Tried 3 more. 1 shows significantly more time in libm on AArch64 over AArch32.
Meetings/mail/etc - [2/10]
=Plan=
cbuild2 benchmarking
* Make sure reporting works
* Get working in either LAVA or 'new TCWG infrastructure'
* Test repeatability
* Get SPEC 2000 working
* Possibly have another go at building tools on AArch64
libm exerising
* Keep working through the list of benchmarks
* Hopefully reach the end and do some analysis
== Issues ==
* none.
== Progress ==
* GCC 4.9 and 4.8 2014.11 (1/10)
- Reviewed FSF branch Merges.
* Lab move (3/10)
- Cherry-picked cbuildv2 master patches in schroot-test
- Created a new jenkins job to tst the "schroot lab move" branch
- The job is able to build all the targets but validation still not works
* Misc: (6/10)
- Caught up with mails and irc logs
- Prepared a patch that add __LINARO_[RELEASE|SPIN]__ macros.
- Reviewed libatomic_ops upstream patch
- Validate libunwind upstream patch
- Various meetings.
== Plan ==
* Back on backports
* Tuesday off (11/11)
= Progress ==
* TCWG-544 - Investigate core mark performance with both at -O3 with
LTO + PGO (6/10)
Different IPA inline decisions happening between Linaro and trunk.
No major differences in other IPA passes. Trunk Inlines crcu32 and not
inlines crcu16. Inlining crcu16 decreases instruction count. Honza
pointed out a patch which inlines fucntions based on profile feedback
and ignores max inlines parameters. It could be reason why trunk
inlines crcu32 and then prevents inlining crcu16. Need to explore on
this.
* Bug fix - Linaro 849. Reproduced and tested it with trunk revision
which fixes it. It looks to be same issue as upstream pr62308 (1/10)
* Misc [3/10]
Emails, linaro and AMD status meetings.
1-1 with inline mangers (Mev, Ryan).
1-1 with christophe.
== Plan ==
* Debug and understand the inline differences trunk vs linaro
compiler for core mark at -O3 with LTO + PGO.
* Expecting one Aarch64 Enablement task.
* Leave on 11/11/2014.
== This week ==
* GCC Modularization Project (9/10)
- Flattening header files
- gimple-streamer.h, tree-streamer.h, lto-streamer.h
- Additional updates based on review:
- Created new header files to contain prototypes from .c files
- Boostrapped changes
- New changes being reviewed
- tree-core.h, cfgloop.h, df.h
- Removed unnecessary includes
- Created new header files to contain exports from .c files
* Misc. (1/10)
- Conference calls
== Next week ==
- Continue flattening of header files on GCC modularization project
- Vacation November 12-14th
== Progress ==
* Zero/sign extension elimination with widening types (TCWG-546 - 9/10)
- benchmarked Spec2k and the improvements are very small
- Coremark fared worse. Looked into the cases and relaxed some of the
constraints.
- Subsequent passes are also not optimizing some of the expected cases
- Re-factored and posted an RFC patch for comments at
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00756.html
* Improve block memory operations by GCC (TCWG-142 - 1/10)
- Looked at the test-cases and gcc dumps
== Plan ==
* Continue with improve block memory operations by GCC.
* Continue with Zero/sign extension pass based on feedback.
== Progress ==
* GCC 4.8 and 4.9 releases (2/10)
- committed both branch merges after review+checked the validation results
- 4.8 needs another branch merge, to get the last errata-related backport
* GCC trunk/4.9 cross-validation (1/10)
- committed a couple of patches to clean the testsuite
- observed a couple of regressions, no time to investigate/report
* AArch64 sanitizer
- got agreement in principle for a new patch, which would test the
kernel headers version.
* Neon intrinsics tests update (1/10)
- the 2 PR I created last week are probably duplicate.
- ARM posted patches to fix problems in the same area, but don't fix these PRs
* cbuild2
- no progress
* Misc (6/10)
- calls, meetings, support
== Next ==
- Tuesday 11th public holiday
* AArch64 sanitizer
* Neon intrinsics update
* GCC linaro 4.8/4.9 releases
* cbuild2:
- analyze previous results
- look at backport-test and tcwgweb scripts+logs
== Progress ==
* Automation Framework (CARD-1378 4/8)
- Moving TCWG machines to the new office
- Setting up new rack, stacking boards, etc.
- Setting up Junos
* Buildbots (TCWG-76 2/8)
- Moving buildbots to the new office
- Checking libcxxabi failure, marking as XFAIL
- All bots green
* Background (2/8)
- Code review, meetings, discussions, etc.
* 1 day ill
== Plan ==
* Continue lab migration
Hi,
When updating:
>From git://git.linaro.org/toolchain/binutils-gdb
e0f5246..336649d master -> linaro/master
I now get the following build error:
gdb/binutils/readelf.c: In function ‘process_mips_specific’:
gdb/binutils/readelf.c:13522:3: error: format ‘%lu’ expects argument of type
‘long unsigned int’, but argument 2 has type ‘size_t’ [-Werror=format=]
printf (_("<symbol index %lu exceeds number of dynamic symbols>"), i);
^
Thanks,
Cov
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
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
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
cbuild2 benchmarking - TCWG-360 [8/10]
* Scripts build SPEC 2006 tools on x86_64 and arm, not yet on AArch64
* Scripts cross-build for x86 to arm and aarch64
* Cross-built binaries refuse to run
Meetings/mail/etc - [2/10]
=Plan=
cbuild2 benchmarking
* Make cross-built binaries run, collect reports
* Build tools for AArch64 (lower priority)
libm exerising
* Work through list of benchmarks, see what I find
= Progress ==
* TCWG-544 - Investigate core mark performance with both at -O3 with LTO +
PGO (6/10)
* Misc [3/10]
emails, linaro and AMD meetings and 1-1 with inline manger.
1-1 with christophe.
* Tried to reproduce Bug 63653 (1/10)
== Plan ==
* Continue core mark performance with both at -O3 with LTO + PGO.
* Continue Bugfix 63653
== Progress ==
GDB Tracepoints/Fast Tracepoints support on arm [TCWG-480] [3/10]
-- Investigate arm hardware debugging capabilities in linux kernel.
ARM/AArch64 GDB testsuite failures investigation [TCWG-507] [4/10]
Trying out patches that add support for gdbserver catch vfork/fork
[TCWG-507] [2/10]
Miscellaneous [1/10]
-- Meetings, Emails etc
-- Annual Review 2014
== Plan ==
Monday/Tuesday Public Holidays in Pakistan.
Fix watchpoints-reuse-slot tests for arm somehow to allow skipping
unsupported tests
Also investigate the same on AArch64. [TCWG-507]
Re-submit some hanging patches after a bit of rework to grab attention.
== This week ==
* GCC Modularization Project (7/10)
- Decided on work near term work objectives with Andrew Macleod
- Began flattening header files
- gimple-streamer.h (complete)
- tree-streamer.h (complete)
- lto-streamer.h (complete)
- tree-core.h (In progress)
- cfgloop.h (In Progress
- df.h (In progress)
* Vector Extensions Project (2/10)
- Design work on C++ classes
- Call with Charles Baylis to discuss libvpx benchmark
* Misc. (1/10)
- Conference calls
- ARM required online training
== Next week ==
- Continue flattening of header files on GCC modularization project
- Further review of libvpx and vector extensions design work
== 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
== 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
== 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
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
> ************************************************
>
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..
Hi All,
There will be lab downtime in the month of November, and rather than
jeopardize the November quarterly binary toolchain release we've decided to
take some steps to ensure that it takes place on time.
The November binary toolchain quarterly release will contain some ARM64
erratum fixes. These are already in the Linaro GCC 4.9 2014.10 source
package release.
The November binary toolchain quarterly release will contain these fixes,
and will be delivered as planned, but will be based on the Linaro GCC 4.9
2014.10 package. We will not have a November Linaro GCC 4.9 2014.11 source
package release.
The December release will be the next Linaro GCC 4.9 source package release.
--
Ryan S. Arnold
Linaro Toolchain Working Group - Engineering Manager
www.linaro.org
cbuild2 benchmarking - TCWG-360 [2/10]
* Figured out how to cook my own OE images
* Started remembering how to build spec
libm exercising - CARD-1693 [2/10]
* Borrowed a usable Juno
* Found that lapack tests segfault on AArch64
* Ran linpack hpl, didn't observe it exercising libm much
** Haven't ruled out Bernie-error yet, though
Upstream - CARD-341 [1/10]
* Respun lowlevellock.h comments
Meetings/mail/etc [5/10]
* A lot of time (>3/10) in performance review and other annual ARM admin
* Some back and forth about difficulties of userspace access to ID registers
=Plan=
Get spec2006 working via my scripts
Find a good HPL libm exerciser
Spend a lot less time on ARM admin
== Progress ==
Further progress on GDB Tracepoints/Fast Tracepoints support on arm
[TCWG-480] [6/10]
-- Debugging and trying out some code enabling tracepoints in gdbserver
-- Research on past tracepoint patches and x86 vs arm architecture comparison
ARM/AArch64 GDB testsuite failures investigation [2/10]
Miscellaneous [2/10]
-- Meetings, Emails etc
-- Fix SSH configurations
-- Patch Scrolling
-- Hong Kong visa process
-- Multiple Dr visits due to continued sickness
== Plan ==
Further progress on GDB Tracepoints/Fast Tracepoints support on arm [TCWG-480]
Fix internet latency issues from lab hardware.
= Progress ==
* Short week was in vacation (22-24 October)
* Updated perf profile numbers for instruction count and documented my
analysis for Linaro compiler's O3 + LTO comparison on Aarch64 vs X86_64
(TCWG-544) (2/10)
* Misc [2/10]
emails, AMD meetings and 1-1 with inline manger.
1-1 with christophe.
== Plan ==
* Coremark benchmark and profiling.
Investigate trunk degradation for O3+ PGO + LTO and report.
== Progress ==
* Zero/sign extension elimination with widening types (TCWG-546 - 10/10)
- Re-wrote the pass from the results of experiments so far
- Fixed most of the regression failures
- 5 tests are still failing from C/C++/Fortran regression suite.
== Plan ==
* Continue with Zero/sign extension pass.
- Get bootstrapping for ARM and AArch64 working
- Fix remaining regression failures
- Add detail dumps
- Remove unnecessary copies (it is now being removed dead code
elimination pass)
- Get patch ready for upstream discussion
== This week ==
* GCC Modularization Project (5/10)
- Reviewed Re-Architecture GNU Cauldron videos by Andrew Macleod
- Reviewed tree/gimple source base
* Linaro bugzilla 602 - gcc 4.7.3 compiler internal error while building
hsail components (2/10)
- Resolved bug by determining that 4.7 compiler was assinging a
incorrect VFP register to a parameter
- Issue was fixed in 4.8 by adding call to arm_hard_regno_ok which
disallowed register
* vector Extensions Project (2/10)
- Preliminary design work on C++ classes and libvpx review
* Misc. (1/10)
- Conducted interview with Prathamesh Kulkarni
- Conference calls
== Next week ==
- GCC Modularization draft plan to TCWG group for review
- Understand status of Re-Architecture work by Andrew Macleod
- Further review of libvpx and vector extensions design work
=== Progress ===
SPEC Benchmarking [5/10]
. managed to run SPEC2k
. managed to run integer parts of SPEC2k6
. spec2xxx-report fails
. can't run full suite as LAVA Junos have insufficient disk
NEON error reporting bugs #403/#418 [3/10]
. ongoing mailing list discussions
vldN_lane patches [1/10]
. respun and committed
Misc [1/10]
=== Plan ===
Talk to Tejas @ ARM about AArch64 NEON loads/stores
Review prep
Move office
Day off at some point (likely Wednesday)
Short week, 2 days off
== Progress ==
* GCC trunk/4.9 cross-validation (2/10)
- committed testsuite patch to support forcing -mword-relocations
option when compiling testglue.c
* Neon intrinsics tests (2/10)
- committed the 1st batch (21 commits)
* AArch64 sanitizer
- libsanitizer internal data depend on the kernel headers version
used to build the toolchain, old_[gu]id_t type changed in 3.15.3.
- discussing the best way to address this
* Misc (2/10)
- calls, meetings
== Next ==
* 4.8 branch merge for next release
* GCC trunk/4.9 cross-validation
- investigate abi_check test, probably another testsuite harness
configuration issue
* AArch64 sanitizer
* Neon intrinsics tests update
* cbuild2:
- analyze previous results
- look at backport-test script + logs
== Progress ==
* Automation Framework (CARD-1378 1/10)
- Setting up Junos with ARM
* Toolchain (CARD-862 1/10)
- Some progress on fpu parser issue
- Produced a lot more work for the near future
* Buildbots (TCWG-76 4/10)
- Setting up a libc++ buildbot, working on reducing failures
- Some bots broken, bisecting
* Background (4/10)
- Code review, meetings, discussions, etc.
- Annual review
- More lab move planning
- EuroLLVM meetings and planning
== Plan ==
* US LLVM whole next week
The Linaro Toolchain Working Group (TCWG) is pleased to announce the 2014.10
release of the Linaro GCC 4.9 source package.
Linaro GCC 4.9 2014.10 is the seventh Linaro GCC source package release. It is
based on FSF GCC 4.9.2-pre+svn216130 and includes performance improvements and
bug fixes.
With the imminent release of ARMv8 hardware and the recent release of the
GCC 4.9 compiler the Linaro TCWG will be focusing on stabilization and
performance of the compiler as the FSF GCC compiler. The Linaro TCWG provides
stable[1] quarterly releases and monthly enginering[2] releases.
Interesting changes in this GCC source package release include
* Updates to GCC 4.9.2-pre+svn216130
* Backport of [AArch64] Define TARGET_FLAGS_REGNUM
* Backport of PR target/61565
* Backport of [AArch64] libitm: Improve _ITM_beginTransaction
* Backport of [AArch64] Fix *extr_insv_lower_reg<mode> pattern
* Backport of [AArch64] Use CC_Z and CC_NZ with csinc and similar instructions
* Backport of [AArch32] Implement and vectorize lceil, lfloor, lround optabs
with new ARMv8-A instructions
* Backport of [AArch64] Improve epilogue unwind info rth
* Backport of [AArch64] Add a mode to operand 1 of sibcall_value_insn
* Backport of [AArch64] Add a builtin for rbit(q?)_p8; add intrinsics and tests
* Backport of [AArch32/AArch64] Schedule alu_ext for Cortex-A53
* Backport of [AArch64] Remove varargs from aarch64_simd_expand_args
* Backport of [AArch64] Tidy: remove unused qualifier_const_pointer
* Backport of [AArch32/AArch64] Add scheduling info for ARMv8-A FPU new
instructions in Cortex-A53
* Backport of [AArch32] Convert FP mnemonics to UAL.
* Backport of [AArch32] Enable auto-vectorization for copysignf
* Backport of [AArch32][tests] Make input and output arrays 128-bit aligned in
vectorisation tests
* Backport of [AArch64] Add crtfastmath
* Backport of PR target/56846 libstdc++
* Backport of PR target/63209
* Backport of [Ree] Ensure inserted copy don't change the number of hard
registers
* Backport of [AArch64] Fix force_simd macro in vdup_lane_2
* Backport of [AArch32] Disallow -mfpu=neon for unsuitable architectures
* Backport of [AArch32] movmisalign<mode>_neon_load
* Backport of [AArch64] Add constraint letter for stack_protect_test pattern
* Backport of [AArch64] Auto-generate the "BUILTIN_" macros
Feedback and Support
Subscribe to the important Linaro mailing lists and join our IRC channels to
stay on top of Linaro development.
** Linaro Toolchain Development "mailing list":
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
** Linaro Toolchain IRC channel on irc.freenode.net at @#linaro-tcwg@
* Bug reports should be filed in bugzilla against GCC product:
http://bugs.linaro.org/enter_bug.cgi?product=GCC
* Questions? "ask Linaro":
http://ask.linaro.org/.
* Interested in commercial support? inquire at "Linaro support":mailto:
support(a)linaro.org
[1] Stable source package releases are defined as releases where the full Linaro
Toolchain validation plan is executed.
[2] Engineering source package releases are defined as releases where the
compiler is only put through unit-testing and full validation is not
performed.
Hi,
I start to use Linary AArch64 toolchain recently and just joined this maillist. I went through some of the archived threads but didn't read all of them. So bear me if I'm asking dumb question or old question which had been answered before.
For our use case, we are running the gdb client at early state of boot. So the ARMv8 target might be running into any EL and into either AArch64 or AArch32 state. My questions are:
1) Is the aarch64-none-elf-gdb.exe good for both AArch64 and AArch32 or I have to run the arm-none-eabi-gdb.exe if the target running in AArch32 state?
2) If the target is in AArch64 state, can I use the aarch64-none-elf-gdb.exe to load binary built for AArch32 to the target?
I'm really appreciated if anybody can help me on these two questions.
Thanks in advance,
StrongQ
cbuild2 benchmarking - TCWG-360 [3/10]
* A few small enhancements and bug-fixes
* Tried to run spec2006 on Juno, looks tricky
libm profiling - CARD-1693 [3/10]
* Pulled together lapack + blas
* Looked a bit at how it exercises libm on x86
* Tried to look at how it exercises libm on Juno, looks tricky
Meetings/mail/etc [4/10]
* Featuring some fun with backups and ARM performance review season
=Plan=
* cbuild2 benchmarking - keep chipping away at spec/juno
* libm profiling - attempt to assemble an AArch64 setup that works for me
* further performance review/corporate admin will take up extra time
this week, but should then fall back to normal levels
=Issues=
State of the setup on our Junos
== Progress ==
* Part way through integrating Cbuild2/Jenkins with Gerrit. (#1692,
8/10)
- Implemented functions to use the REST API to Gerrit via SSH.
- Integrated into build and test processes.
* Meetings and Misc (2/10)
- Ordered 10 Snapdragon boards
== Plan ==
* Finish Gerrit integration with Cbuild2 and Jenkins. (#1692)
- Find a way the buildslave user can use the SSH connection to Gerrit.
* Start merging the linaro branch in DejaGnu to master to get
ready for the next release.
* Start getting ready for the lab move, do what I can ahead of time.
== Issues ==
* Gerrit comments via REST strip out all newlines, so I need to
limit the message size after a test run.
= Progress ==
* Core mark benchmark and report for PGO and PGO + LTO (TCWG-544) (6/10)
Going by CPU cycles adding LTO gains in x86 and degrades in Aarch64 .
Looked at hot functions and examining assembly the code generation seems to
be same. X86_64 does alignment of code. Also branch misses decreased in
X86_64 compared to Aarch64 with -flto + -O3.
Also profiled for instruction counts on Aarch64 with linaro compiler. These
profiles say that we are executing less instructions with LTO and PGO for
Aarch64.
* PR 63173- Reproduced the issue and changed the test case to work with
trunk. Now Looks like someone else has a patch for it. (1/10). so will
work on other bugs.
* Misc [3/10]
Internal work, emails, AMD meetings and 1-1 with inline manger.
1-1 with Maxim, christophe and 1-1 with ryan
== Plan ==
* Coremark benchmark and profiling.
Investigate trunk degradation for O3+ PGO + LTO and report.
== leaves ==
Diwali holiday (22-24)
== Issues ==
* Still no network at home and will not be fixed before at least one week :(
== Progress ==
* GCC 4.9 2014.10 (8/10)
- Merged FSF 4.9 branch
- Released Linaro 4.9 2014.10
* Misc: (2/10)
- Various meetings.
== Plan ==
* Analyse some failures that occur only in --enable-release.
== Progress ==
Catch up with work after return from Eid ul Adha and Annual Holidays [7/10]
* Hong Kong visa application
* UPS repairs and office cleanup
* Catching up with work, gdb roadmap and open/running cards.
* Emails/Patch scrolling/Meetings etc
* Sick day off on Monday
GDB Tracepoints/Fast Tracepoints support on arm [TCWG-480] [3/10]
* Getting re-synced with code where I left.
== Plan ==
Further progress on GDB Tracepoints/Fast Tracepoints support on arm [TCWG-480]
Investigate possibility of AArch64 trace-point work without
availability of hardware.
Check for GDB status on ARM and AArch64 vs x86.
== Progress ==
* Zero/sign extension elimination with widening types (TCWG-546 - 9/10)
- Fixed ICEs and now can build the cross compiler and do the regression
testing with qemu
- some test-cases are failing due to condition that rely on overflow;
this need fixing.
- Bootstrapping on AArch64 still fails (but much later than previously).
- Verified CRC is optimized
* Improve block memory operations by GCC (TCWG-142 - 1/10)
- Looked at the changes since the card was drafted
== Plan ==
* Continue with Zero/sign extension pass.
== Progress ==
* GCC trunk/4.9 validation (CARD-647) (3/10)
- committed testsuite patch to test if -shared is supported
- forcing -mword-relocations flags when compiling testglue works on
my Ubuntu machines, but does not in the Compute Farm RHEL5 servers.
- investigating why, all the more as it made me incorrectly report
failures in the 4.9 branch
* Validation (2/10)
- compared cbuild2 schroot-test branch and master
the results of this manual run does not seem to match Jenkins results
* Neon intrinsics tests (1/10)
- fixed .exp harness to support parallelization
- looking at how to pre-support fp16, will probably skip it for now,
and add dedicated tests later
* AArch64 sanitizer (1/10)
- GCC trunk seems to need to cherry pick a sanitizer patch when
building using recent kernel headers
- tried to use Jenkins to build trunk and trunk+cherry-pick, but the
results are not consistent
needs more investigation
* Misc (3/10)
- calls, meetings, irc
== Next ==
* GCC trunk/4.9 cross-validation
- fix -mword-relocations support
- investigate abi_check test
* AArch64 sanitizer
* Neon intrisics tests update
* cbuild2:
- analyze previous results (mostly check the logs....)
- look at backport-test script + logs
Short next week: off Wednesday/Thursday
== Progress ==
* Respin of malloc single-thread optimizations (4/10, TCWG-436)
- Create a generic header, include AArch64 in series
* Further work on malloc app benchmark framework (4/10, TCWG-441)
- Cleaned up, improved reliability, added comments
- Committed to cortex-malloc.git
* Email, meetings, etc. (1/10)
* Upstream work (1/10, CARD-341)
- glibc patch review and pings
- Look into some bug reports and testsuite failures
== Issues ==
* Electricians and gas engineers turning off power/heating at various points
== Plan ==
* Hopefully get some resolution of single thread atomic stuff for glibc
--
Will Newton
Toolchain Working Group, Linaro
== Progress ==
* Linux Plumbers (6/10)
- Attended conference, Android/Tools/LLVM tracks
- Presented 2 talks (GCC+LLVM and LLVM+ARM)
* Buildbots (TCWG-76 2/10)
- Made the Compiler-RT bot green! Now on to the libc++ one
* Background (2/10)
- Code review, meetings, discussions, etc.
- Internet upgrade, re-wiring the house, building works
== Plan ==
* Add libc++abi buildbot
* Follow up on the fpu issues on Clang/asm
FYI.
The whole thread is available here:
http://article.gmane.org/gmane.linux.ports.arm.omap/119412
---------- Forwarded message ----------
Date: Thu, 16 Oct 2014 01:18:01 +0100
From: Russell King - ARM Linux <linux(a)arm.linux.org.uk>
To: Peter Hurley <peter(a)hurleysoftware.com>
Cc: Nathan Lynch <Nathan_Lynch(a)mentor.com>,
David Laight <David.Laight(a)ACULAB.COM>,
Otavio Salvador <otavio(a)ossystems.com.br>,
Linus Torvalds <torvalds(a)linux-foundation.org>,
Nicolas Pitre <nico(a)fluxnic.net>,
Linux OMAP Mailing List <linux-omap(a)vger.kernel.org>,
linux-arm-kernel(a)lists.infradead.org
Message-ID: <20141016001801.GQ12379(a)n2100.arm.linux.org.uk>
Subject: Re: [PATCH] ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854
On Wed, Oct 15, 2014 at 06:18:30PM -0400, Peter Hurley wrote:
> On 10/15/2014 05:56 PM, Russell King wrote:
> > I was in two minds whether to include 4.8.3 as Linaro released a buggy
> > toolchain which identifies itself as 4.8.3, but I decided that's also
> > a distro problem. IMHO Linaro should really think about taking that
> > compiler down given the seriousness of this bug and it being
> > indistinguishable from the fixed stock version.
>
> Maybe it's unfair to blame them; Linaro just took a snapshot and
> released what was there.
>
> If gcc is going to retain the "change release number then add all the
> new features" model, some kind of prerelease indicator would help
> eliminate this kind of problem. And that indicator should be both
> a preprocessor define and parseable from the command line :)
My comment is not to attribute blame to them, my comment is entirely
on a technical level.
My reasoning is that the bug is just as prevalent in userspace, though
it will occur less often. Any program which uses signal handlers is
a candidate for exactly the same kind of corruption, since you can
receive that signal between the point that the stack pointer is
modified and the function loads the parent context.
Of course, there are ways around that: don't use signal handlers, or
if you do, use alternate signal stacks. Neither of those can be
guaranteed for any program though.
So, let me put this another way: a compiler with this bug is _completely_
unsuitable for use for compiling programs for use under the Linux
kernel _as well_ as the Linux kernel itself.
The difference is that the Linaro compilers come with an expectation
that they are usable on ARM... whereas stock versions cover a lot more
and so the ARM arch is probably very small number of their users.
Hence why I recommend that Linaro takes down their buggy compiler.
Their 4.8.3 version should not be used *anywhere*, just the same as
the stock 4.8 to 4.8.2 inclusive should also not be used anywhere on
ARM either.
== Progress ==
Neon vld/vst [4/10]
. submitted v2 of vldN_lane patch (respin of patches 1&2 only)
. continued ML discussion about patches 3&4.
Tried out jenkins/cbuild infrastructure [1/10]
. hardest part was getting git.linaro.org/people to hold my test tree
. https://wiki.linaro.org/Platform/Systems/GitServer#Creating_new_repositories
. if it doesn't work, ask ITS to check you are in the git-users group
. still need to find where the results go.
bug 403/418 wrong line number on neon error messages [2/10]
. experimented with a couple of ways to solve this
bug 715 [2/10]
. investigated and closed as only affects deprecated old ABI
Misc [1/10]
== Plan ==
Benchmark 2014.10 release
Continue bug 403/418 work
== Progress ==
* Further work on malloc single-thread optimizations (2/10, TCWG-436)
- Still pending some resolution on direction from upstream
* Upstream work (1/10, CARD-341)
- Patch review
- Applied binutils patch for missing AArch64 relocs
* Further work on malloc app benchmark framework (2/10, TCWG-441)
- Found a possible way to get memory statistics without hacks, should improve
speed and reliability of the benchmark framework
* Email, meetings, etc. (1/10)
* Thursday and Friday annual leave (4/10)
== Issues ==
* None
== Plan ==
* Get malloc app benchmark framework into shape and committed
* Figure out direction for malloc single thread optimization work
--
Will Newton
Toolchain Working Group, Linaro
cbuild2 benchmarking - TCWG-360 [7/10]
* Fixed/worked around some especially resilient bugs
** Mostly relate to running benchmarks through LAVA, which may be less
important in the near future
* Wrote a doc
* Upstreamed some code that works about as I want it to
Meetings/mail/etc [3/10]
=Plan=
cbuild2 benchmarking
* Work through TODO list from connect
* Tidy up behaviour on shutdown
* Storage issues
* (Maybe) persuade a LAVA Juno to work for benchmarking or configure spec
Hopefully pick up something else
= Progress ==
* Core mark benchmark and report for PGO and PGO + LTO (4/10)
More profiling and collected numbers and reported. JIRA card TCWG-181 updated.
Adding LTO gains in x86 and degrades in Aarch64 .
* Addressed machine bring up issues, debugged and installed necessary
packages for both x86 and Aarch64 (1/10)
* PR 62308 - Analyzed RTL dumps. Looks to be similar issue solved in
trunk. Git bisected and found the passing revision in trunk. posted my
comments. waiting for feedback. (2/10)
* Misc [3/10]
Internal work, emails, AMD meetings and 1-1 with inline manger.
1-1 with Maxim, christophe and 1-1 with ryan
Linaro status call
== Plan ==
* Coremark benchmark and profiling for PGO and PGO + LTO. Investigate
LTO degradation causes and report.
* Investigate PR 63173
* Setup Cbuildv2 build in internal machine.
== Issues ==
Experiencing Hardware connection issues and kernel instability issues
with my local machines.