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