- linaro-toolchain - lists.linaro.org

[ACTIVITY] 13-17 January 2013

by Christophe Lyon

- 2014.01 releases: (2/10) * 4.7 ready, 4.8 needed a short daily to include our multilib patch to support our binary releases. * retried cbuildv2 and sent feedback. Should be mostly OK by now. - cross-validations: (2/10) * followup-up, bugzilla * thinking about short term Neon intrinsics testsuite use without dejagnu - libsanitizer (2/10) * resumed work for aarch64 - misc (2/10): conf-call and meetings - internal support (2/10) * issue: boards used for benchmarking have been off for several weeks. Pending jobs disappeared from the list, but I got no log.

11 years, 7 months

1
0
0 0

[ACTIVITY] 13 - 17 January 2014

by Omair Javaid

== Progress == * Implement fork over HW breaks support for arm native targets. [TCWG-177] [6/10] * ARM Process Record: - All patches accepted and upstream. - Spent time making changes to VFP, SIMD etc patch. [2/10] - Configuration and Git ssh setup for gdb commit rights . [1/10] * Submitted a new fix and worked with community for the fix. [1/10] == Plan == * Continue to work on fork over HW breaks support for arm native targets. [TCWG-177] * Patch updates and submission to all in progress upstream submissions. * Travel to Islamabad for Macau visa application.

11 years, 7 months

1
0
0 0

[Activity] 13 Jan - 17 Jan 2014

by Venkataramanan Kumar

== Progress == * Libc probes support for Aarch64. Testing the patch for "libc" probes support to "__longjump". Native compiling in openemebedded. Obtained a Linaro open embedded image with system tap enabled. Getting Assembler Error during "malloc" module linking in "glibc" configured with --enable-systemtap. In libc_mallopt invalid "asm", invalid expression as operand for LIBC_PROBE call. Cross compiling. Tried copying header files from system tap source to SYSROOT for cross compiling glibc. The cross compiled GCC does not recognize the header files. * Investigate "PGO" for Aarch64. Started bootstap testing GCC with PGO for GCC. Stage 1 completed. stage profile in progress. == Plan == - Run EMBCC benchmark with -PGO enabled. - Work on "glibc" probe. == Issues == Waiting for feedback on "libssp" machine descriptions changes. Misc ------ 14-Jan-2014 Local holiday.

11 years, 7 months

1
0
0 0

[ACTIVITY] 13 - 17 January 2014

by Kugan

== Progress == - TLS GOT binutils patch and gcc fix for aarch64_build_constant are committed upstream. (1/10) - TCWG-360 (closed) (1/10) - TCWG-349 (closed) (4/10) - set-up trunk daily regression (4/10) - Resolved issues running address sanitiser with qemu - started running daily cross regression testing with qemu and native regression testing on chromebook. - Started analysing failures. == Plan == - Continue with trunk daily regression - Look at pending optimization cards

11 years, 7 months

1
0
0 0

[ACTIVITY] Week 03

by Zhenqiang Chen

== Issues == * None. == Progress == * Test Linaro cbuildv2. - Write a reference script to support windows installer in cbuildv2. - Do some basic validation work against the binaries built from cbuildv2. * Reproduce and work out a patch for "ICE when building linux-linaro-tracking" (lp:1268893, PR59837) . * Test to merge Linaro local armv4t multilib patch to Linaro 4.8. * Investigate CCMP chance by taking a Bool_ var as var != 0. == Plans == * cbuildv2 validation * Tuning ccmp performance == Planed leaves == * Jan. 31 - Feb. 9.

11 years, 7 months

1
0
0 0

[Weekly] 13-17 Jan 2014

by Michael Collison

== This week == - Completed merge of crypto backports 206128, 206130, 206131, 206132 and 206149 from trunk to Linaro 4.8 branch - Out sick Friday == Next week == - Build and test crypto backports - Begin merging aarch64 crypto backport to Linaro 4.8 branch == Future ==

11 years, 7 months

1
0
0 0

[ACTIVITY] Week 3 (Jan 13-17 2014)

by Ryan Arnold

== Progress == * Cbuildv2 fix for *_release() functions which were changing out of the build directory but then not changing back to the builddir, which caused problems with paths relative to the builddir. (1/10) * TCWG-340 Enable Glibc remote testsuite integration - (7/10) - Working with upstream community on scoping and designing remote testsuite integration. - Setting up arm chroot environment on chromebook with documentation on how to make this reproduceable. * TCWG-352 AArch64 clone is missing some CFI markup - (2/10) - Setup aarch64 environment for testing and built static clone tests to test the patch. == Plan == * Start implementing (code) for glibc remote testsuite integration. == Issues == None

11 years, 7 months

1
0
0 0

[ACTIVITY] Week 3

by Renato Golin

== Progress == * Buildbots - Odroid U2 died after a few days on USB stick, too. (I guess we're stuck with Chromebooks) - Upgrading chromebooks (to Saucy) due to a new GCC/libstdc++ 4.7+ restriction - Shuffling chromebooks, we now have three buildbots: - llvm-chrome-01: quick-build+check - llvm-chrome-02: self-host+check - llvm-chrome-03: test-suite * MCJIT Remote - Re-factored the communication protocol of MCJIT for remote processes - Still seeing one random failure on ARM, investigating * Compiler-rt - Investigating how to get it compiling all libraries and sanitizers on ARM * Background - Patch reviews, especially IAS and EH * Time - CARD-862 8/10 - Others 2/10 == Plan == * Continue MCJIT and Compiler-RT investigations * Continue reviewing IAS and EH patches * Try to run the EH tests on the test-suite with the current changes

11 years, 7 months

1
0
0 0

[ACTIVITY] 13 - 17 January 2014

by Will Newton

== Progress == * Add support for AArch32 ARMv8 VRINT to QEMU (4/10, TCWG-50) * Add support for AArch32 ARMv8 VCVT to QEMU (4/10, TCWG-49) * Add support for AArch32 ARMv8 16<->64bit VCVT to QEMU (1/10, TCWG-51) * Fixed gas ARM VCVT encoding bug (1/10) == Issues == * None == Plan == * Complete outstanding QEMU work * ARM setjmp/longjmp SystemTap probes * malloc -- Will Newton Toolchain Working Group, Linaro

11 years, 7 months

1
0
0 0

ICE when building linux-linaro-tracking

by Koen Kooi

Hi, I've been playing with linux-linaro-tracking and the 2013.12 (and 2013.10, 2013.11) toolchain release and when turning on the NEON in kernel option I get: CC lib/raid6/neon4.o lib/raid6/neon4.c: In function 'raid6_neon4_gen_syndrome_real': lib/raid6/neon4.c:113:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1078 } ^ Use the attached .txt as .config and do 'make zImage' to replicate the problem. You will probably need to attached patch as well since some of the linaro patches break namespace support :( regards, -- Koen Kooi Builds and Baselines | Release Manager Linaro.org | Open source software for ARM SoCs

11 years, 7 months

3
8
0 0

[ACTIVITY] Week 2

by Yvan Roux

* Two days week (due to compilation courses given at university). == Issues == * none == Progress == * LRA on AArch32: o TCWG-343 : Make LRA the default for the ARM backend (1/10) - iWMMXT issue : back on the issue. - Thumb1 issues : looked at bugzilla's reports. o TCWG-345 : Analyse performance of LRA for ARM. (0/10) - No progress this week. * Loop specialization patch review: (1/10) o Back on the task. * [Bug 1258013] Re: Cannot build arm64 kernel with CONFIG_DEBUG_INFO=y (1/10) o Tried to reproduce the issue. * Misc. (1/10) o Catching up with email, etc o Meeting == Next == * Still some time spend at university * Continue the ongoing tasks. * Branch merge reviews.

11 years, 7 months

1
0
0 0

[ACTIVITY] 6 - 10 January 2014

by Omair Javaid

== Progress == * ARM Process Record: - Follow up on patches, almost all patches accepted. [0.5/10] - Got GDB committ rights and set up git for pushing patches. [0.5/10] * Spent time to read through fortran functions prologue to find a new fix for TCWG-267. [1/10] * Initial investigation of handling breakpoint over fork [TCWG-177] [1/10] * Getting documentation ready for Macau visa application [2/10] == Plan == * Update and send patches where required and committ all approved patches. * Work on breakpoints issues [TCWG-177] and reverse stepping through solib issue [TCWG-315] * Apply for Macau visa, given all documents get ready.

11 years, 7 months

1
0
0 0

[Activity] 06 Jan - 10 Jan 2014

by Venkataramanan Kumar

== Progress == * Libc probes support for Aarch64. Posted patch for "libc" probes support to "__longjump". Worked on review comments from Maintainers. Upstream discussions in progress. Working on testing "glibc" by using --enable-systemtap. * Experimented with "Cbuildv2" native building. == Plan == - Continue Cbuildv2. - Investigate "PGO" for Aarch64. - Work on "glibc" probe. == Issues == Waiting for feedback on "libssp" machine descriptions changes. misc === 14-Jan-2014 leave.

11 years, 7 months

1
0
0 0

[ACTIVITY] 6-10 January 2014

by Kugan

== Progress == - Zero/sign extension elimination - experimented and discussed upstream. Still no confirmation (2/10) - Bug investigation LP1267122 and LP1263576 (6/10) - CBUILD2 Benchmarking (2/10) - More testing on chrome book == Plan == - Finish CBUILD2 Benchmarking - set-up trunk daily regression

11 years, 7 months

1
0
0 0

[ACTIVITY] Week 2

by Zhenqiang Chen

== Issues == * None. == Progress == * Try cbuildv2 and compare the binaries with current releases. * Identify MULTIARCH_DIRNAME in trunk breaks aarch64 multiarch build. * Branch-cost tune for Cortex-M. == Plans == * Verify binaries built from cbuildv2 == Planed leaves == * Jan. 30 - Feb. 10.

11 years, 7 months

1
0
0 0

[ACTIVITY] Week 1 - Jan 6 - 10

by Ryan Arnold

== Progress == * Draft wiki page (under ACL--let me know if you want to see) for instructions for setting up chroots on chromebooks for glibc testing: https://collaborate.linaro.org/display/~ryan.arnold@linaro.org/Configuring+… * Investigated expanding remote testing possibilities in glibc. * RFC email to libc-alpha discussing proposal for glibc host testsuite in chroots: https://sourceware.org/ml/libc-alpha/2014-01/msg00222.html == Issues == * Shortened week (3-days) because of unplanned school closures on Monday and Tuesday due to freezing temperatures, during which I had to watch my kids. == Plan == * Start code scaffolding for glibc host testsuite in chroot. * Start cbuild2 scaffolding for building remote chroots for glibc testing. * Add glibc multi-lib builds and IFUNC system libraries. * Work on cbuild2 support for local tar files.

11 years, 7 months

1
0
0 0

[Weekly] 06-10 JAN 2014

by Michael Collison

== This week == - Completed local backportS of 201164, 201165, 201166, 201167, 201168. == Next week == - Complete backport of 201175 - Submit merge requestS using git == Future ==

11 years, 7 months

1
0
0 0

[ACTIVITY] Week 1

by Will Newton

== Progress == * Two day week * Catching up on email etc. after break (0.5/10) * Investigate setjmp/longjmp SystemTap probe support in ARM glibc (1/10, TCWG-378) * Investigate toolchain bug reports for ARM and AArch64 (0.5/10) == Issues == * None == Plan == * Resume QEMU ARMv8 AArch32 work * Hopefully push glibc ARM pointer encryption fix for 2.19 -- Will Newton Toolchain Working Group, Linaro

11 years, 7 months

1
0
0 0

[ACTIVITY] 6-10 January 2014

by Christophe Lyon

- 2013.12 releases (1/10) * Sent announcements for 4.7 and 4.8 releases. - 2014.01 releases (2/10) * Created 4.7 and 4.8 branch merge requests (had handle some conflicts in 4.8) * Looked at backporting the crypto intrinsics support into 4.8, but there are dependencies with several other patches we haven't backported yet. - cross validation (4/10) * Restarted them since I had to stop them during the holidays. Still catching up with the backlog, should be OK during the week-end. * Analyzed and reported several regressions or new tests failing in some configurations. - Neon intrinsics tests (1/10) * Looked at Rob's neon-intrinsics branch and sent him some feedback. - misc (2/10): conf-calls and meetings. == Next == - 2014.01 releases - cross-validation: look at results and report regressions if any - resume libsanitizer work for AArch64

11 years, 7 months

1
0
0 0

[ACTIVITY] Week 01

by Renato Golin

== Progress == * Release 3.4 went out * Buildbots - Using powered USB hub for the external harddrive, but all boards fail one time or another... - Maybe it's the hard-drive type (mobile, power-saving), reverting to USB sticks for now - Leaving an odroid U2 running on USB stick for a week, used to work... - C++11 features will need GCC 4.7+, looking for an easy way to upgrade the Chromebooks * MCJIT - Finished work on remote MCJIT to re-enable the failing tests - http://llvm-reviews.chandlerc.com/D2527 * Pragma Vectorize - New discussions hint that my parser patch is moot, for now - Agreement is to use C++11 attributes for now, and add pragmas later - I can't continue implementing them, though... * Background - Huge number of patch reviews during holidays & this week - Good progress on new features for the IAS - More progress on EHABI, including IAS support * Time - CARD-862 8/10 - Others 2/10 == Plan == * Continue reviewing IAS features, maybe implement some * Work out how to create a libcxx bot * re-introduce llvm-chrome-01 as second self-host * Migrate all buildbots to GCC 4.7+ * Check out EHABI tests and assess progress

11 years, 7 months

1
0
0 0

miscompilation of unsigned comparison on aarch64

by Michael Hudson-Doyle

Hi, I filed this on bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59744 but I thought I'd mention it here too. This slightly strangely written program (it's distilled down from frame_offset_overflow in the gcc source itself) should print "bigger" if the first argument is bigger than 10 (or negative, but let's ignore that please): #include <stdlib.h> #include <stdio.h> int a[2] = { 10, 20 }; int is_bigger (long offset, int index) { unsigned long size = -offset; if (size > a[index]) { printf("bigger\n"); return 1; } return 0; } int main (int argc, char** argv) { long v; v = atol(argv[1]); is_bigger(-v, 0); return 0; } When compiled at -O1 or above (and with inlining disabled at -O2 and above), though, it bungles the 0 case: (t-doko)mwhudson@arm64:~$ gcc-4.9 -O3 test.c -o test -fno-inline -Wall (t-doko)mwhudson@arm64:~$ ./test 1 (t-doko)mwhudson@arm64:~$ ./test 11 bigger (t-doko)mwhudson@arm64:~$ ./test 0 bigger (t-doko)mwhudson@arm64:~$ gcc-4.9 -O0 test.c -o test -Wall (t-doko)mwhudson@arm64:~$ ./test 1 (t-doko)mwhudson@arm64:~$ ./test 11 bigger (t-doko)mwhudson@arm64:~$ ./test 0 (t-doko)mwhudson@arm64:~$ What's going on? Here's the disassembly of is_bigger (at O3): 0000000000400608 <is_bigger>: 400608: b0000082 adrp x2, 411000 <_GLOBAL_OFFSET_TABLE_+0x28> 40060c: 91010042 add x2, x2, #0x40 400610: a9bf7bfd stp x29, x30, [sp,#-16]! 400614: 52800003 mov w3, #0x0 // #0 400618: 910003fd mov x29, sp 40061c: b8a1d841 ldrsw x1, [x2,w1,sxtw #2] 400620: ab00003f cmn x1, x0 400624: 540000a2 b.cs 400638 <is_bigger+0x30> 400628: 90000000 adrp x0, 400000 <_init-0x3f8> 40062c: 911b6000 add x0, x0, #0x6d8 400630: 97ffff90 bl 400470 <puts@plt> 400634: 52800023 mov w3, #0x1 // #1 400638: 2a0303e0 mov w0, w3 40063c: a8c17bfd ldp x29, x30, [sp],#16 400640: d65f03c0 ret Basically it seems that the condition "-offset > val" is being compiled as "val + offset does not overflow", which is not valid for offset == 0. This seems to me to be the underlying cause behind https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1263806 ("gccgo fails to compile tomb.go on arm64"). Cheers, mwh

11 years, 7 months

1
0
0 0

help on linaro android toolchain 13.12 (arm-v7)

by Sandeepa Prabhu

Hi, We are trying to build android Kitkat (for our own platform) using linaro android toolchain version 4.7.4 from 13.12 release. We are observing following while compiling some shared libraries: ~arm-linux-androideabi-4.7/bin/../libexec/gcc/arm-linux-androideabi/4.7.4/real-ld: warning: shared library text segment is not shareable ~arm-linux-androideabi-4.7/bin/../libexec/gcc/arm-linux-androideabi/4.7.4/real-ld: error: treating warnings as errors We tried to suppress thisn warning by setting LDFLAGS but the tool-chain does not seem to identify this flag: LOCAL_LDFLAGS := --no-warn-shared-textrel We need some help to fix this, so posting on both android and tool-chain mailing lists. Thanks, Sandeepa

11 years, 7 months

2
1
0 0

LLVM and GCC working together

by Renato Golin

Hi folks, As most of you are on the GNU side of the fence, I believe this is the right crowd to first ask this question, before attempting a wider audience. For a while, Clang/LLVM wasn't in any position to add unheard-of features, and most of what we needed would be covered by something GCC already did. But in the last year or so, there were a number of "features" we'd like to add that aren't present in GCC (like pragmas, attributes, asm directives) which is neither part of the language specifications, nor something that another standard (like OpenMP or ABIs) already support. As a concrete example, we're trying to come up with some vectorisation annotation and there is a heated discussion on whether it should be C++11 attributes, pragmas, or changing the __attribute__ semantics to allow it to be used in lexical blocks, not just declarations. Any of that, but most strikingly the latter, would add Clang-specific behaviour which GCC probably won't implement, and we all know how that feels. In this discussion, and others regarding ARM-specific behaviour (notably about assembly directives), I have used the same argument twice already, so it's time to ask the GCC crowd once and for all: For non-standard, domain or platform specific changes, do we want to have a joint task force, GCC+LLVM, to homogenize the efforts in extending the languages we support in the same say, so that we can call it the "OSS Compiler Extensions" (or whatever) instead of two separate GCC-extensions and Clang-extensions? Historically, GCC has *a lot* more extensions, so this new standard would probably be 99% GCC, but the goals of such a task force for the future would be to: 1. Make sure all OSS compilers implement the same extensions, when they so chose. So, extensions to the language should go in a shared forum, and not to Clang/GCC lists. 2. Document each extension and record all discussions (threads, bugs, etc), so that new compilers can have an easier time implementing them. 3. Reason about the existing hazardous or redundant extensions, and mark them for deprecation. This is also pertinent to the Linux kernel, which is driving its own task force to compiler the kernel with Clang, so that it can rid itself from outdated GNU extensions that lingered for far too long in their code. I appreciate the size of this proposal, the political issues and the endless discussions, but this is the same on every standard committee, and I'd rather have something than nothing at all. Perhaps, as it happened before, some of these changes could be more easily persuaded to move back to the language standards and platforms ABIs, than if it's just implemented, undocumented, by one compiler. So, ignoring just for a moment the political side of it, would that make technical sense for the GCC community as well? cheers, --renato

11 years, 7 months

1
0
0 0

Stable GCC

by Renato Golin

Folks, Since LLVM is moving on to C++11, I need to replace our buildbot GCCs with 4.7+ (the new minimum requirement), but I'd like to use whatever is the most stable and modern GCC version for native compilation. I could get the latest and greatest on our repository, but I know how compilers are written, and pardon me if I don't trust new releases... ;) Does any one have an opinion on which is the most stable, preferably 4.8, release of native ARMv7 GCC binaries? For some odd reason, we just release cross-compilers, so, in that case, where would I look for a native GCC, other than in my Ubuntu/Arch repositories? ARM? CodeSourcery? I *really* don't want to compile it myself... My lack of available fast ARM hardware is disturbing, and I don't want to spend a week cross-compiling GCC. cheers, --renato

11 years, 7 months

1
0
0 0

[ANNOUNCE] Linaro GCC 4.8 and 4.7 2013.12 released

by Christophe Lyon

The Linaro Toolchain Working Group is pleased to announce the release of both Linaro GCC 4.8 and Linaro GCC 4.7. Linaro GCC 4.7 2013.12 is the twentiy first release in the 4.7 series. Based off the latest GCC 4.7.4+svn205768 release, this is the eighth release after entering maintenance. Interesting changes include: * Updates to GCC 4.7.4+svn205768 * Fixed MULTILIB_DEFAULTS in linux-eabi case. Linaro GCC 4.8 2013.12 is the ninth release in the 4.8 series. Based off the latest GCC 4.8.3+svn205577 release, it includes performance improvements and bug fixes. Interesting changes include: * Updates to GCC 4.8.3+svn205577 * AArch64: enable build of libjava and libatomic. Change frame growth direction, thus enabling libssp build. The source tarballs are available from: http://releases.linaro.org/13.12/components/toolchain/gcc-linaro/4.7 http://releases.linaro.org/13.12/components/toolchain/gcc-linaro/4.8 Downloads are available from the Linaro Releases website: http://www.linaro.org/downloads/ More information on the features and issues are available from the release pages: https://launchpad.net/gcc-linaro/4.7/4.7-2013.12 https://launchpad.net/gcc-linaro/4.8/4.8-2013.12 Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain Bugs: https://bugs.launchpad.net/gcc-linaro/ Questions? https://ask.linaro.org/ Interested in commercial support? Inquire at support(a)linaro.org

11 years, 7 months

1
0
0 0

[Activity] 30 DEC-03 Jan 2013

by Venkataramanan Kumar

== Progress == * Pointer mangling Aarch64 glibc. Worked on review comments from Maintainer. Rebased and posted the patch. Upstream completed and closed the card. https://cards.linaro.org/browse/TCWG-373 * Experimented with Cbuildv2 native building. == Plan == - Continue Cbuildv2. - Investigate PGO for Aarch64. == Issues == Waiting for feedback on libssp machine descriptions changes.

11 years, 7 months

1
0
0 0

[ACTIVITY] Week 01

by Zhenqiang Chen

== Issues == * None == Progress == * One day off (Jan. 1) * Do some basic validations for 2013.12 toolchain binaries release. * R/M Mac toolchain validation * Branch-cost related tuning for Cortex-M. == Plans == * Continue on branch-cost related tuning.

11 years, 7 months

1
0
0 0

[ACTIVITY] 30 December 2013 - 3rd January 2014

by Kugan

== Progress == - Short week (4 Days) - TCWG-291 zero/sign extension elimination 4/10 - made re-factoring and ran the regression - benchmarking in progress - TCWG-134 divmod 4/10 - converted into latest pass structure and re-based the patch - found some regression failures and fixed them - regression testing ongoing == Plan == - post divmod and vrp patches

11 years, 7 months

1
0
0 0

[ACTIVITY] 30 December 2013 - 3rd January 2014

by Omair Javaid

== Progress == * ARM Process Record: [TCWG-336] [TCWG-338] [TCWG-339][TCWG-317] [TCWG-315] - Configured and learnt to use git format-patch and git send-email. [1/10] - Incorporated and tested changes suggested by maintainers in previous arm process record patches. [2/10] - Created a new patch series indicating bug fixes separate from features. [1/10] - Submitted version 2 of arm process record replay improvements. * Debugging of stepping over and single stepping heurisitic code. [TCWG-315] [4/10] * Review of open JIRA cards and pending patches [1/10] * Time off for setting up new office space. [0.5/10] * Macau visa information gathering and document preparation [0.5/10] == Plan == * Reverse engineering stepping code heuristics in gdb to find a fix for reverse debugging of solib code on arm. [TCWG-315] * Find and submit a new fix for TCWG-267. * New office space setup and Macau visa application, will be away from my desk for few hours.

11 years, 7 months

1
0
0 0

[ANNOUNCE] Linaro Toolchain Binaries 2013.12 released

by Bernhard Rosenkränzer

Just before having to rename it to 2014, the Linaro Toolchain and Builds and Baselines Working Groups are pleased to announce the 2013.12 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.12 * Linaro GDB 7.6.1 2013.12 * Linaro Binutils 2.24 2013.12 * 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: * Binutils has been updated to 2.24, bringing many improvements * Various bugs have been fixed 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://releases.linaro.org/13.10/components/toolchain/binaries/ 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.

11 years, 7 months

1
0
0 0

[Activity] 23-27 DEC 2013

by Venkataramanan Kumar

== Progress == * Pointer mangling Aarch64 glibc. Posted patch on pointer mangling. Worked on review comments from maintainer. Tested on V8 foundation model. == Plan == - Continue working on review comments for Pointer Guard support in Aarch64 glibc, - Continue Cbuildv2. - Investigate PGO for Aarch64. == Issues == Waiting for feedback on libssp machine descriptions changes.

11 years, 7 months

1
0
0 0

[ACTIVITY] Week 52

by Zhenqiang Chen

== Issues == * None == Progress == * One day off (Dec. 27). * Prepare toolchain binaries release - Backport the newlib patches for ftruncate() and truncate() stubs - Test and update binutils version to linaro-2.24-2013.12 and workaround gold compile fail issue. * Retest -fira-loop-pressure performance on cortex-m4. But get regression in several suites of eembc-v1. Will re-investigate it when aarch64 performance test is ready since it is enabled in ia64 and rs6000, and the comment says: /* Numerous experiment shows that IRA based loop pressure calculation works better for RTL loop invariant motion on targets with enough (>= 32) registers. It is an expensive optimization. So it is on only for peak performance. */ * R/M toolchain related work. == Plan == * Linaro toolchain binaries 2013.12 release

11 years, 7 months

1
0
0 0

[ACTIVITY] 23 - 27 December 2013

by Kugan

== Progress == - Short week (25th and 26th public holidays) - Integrate benchmarking into Cbuildv2 (TCWG-360 4/10) - First cut implementation complete and ready for review - Binutils Bug 16340 (2/10) - Posted modified patch after regression testing and analysing the results == Plan == - ping modified zero/sign extension patch with benchmarking - set-up trunk daily regression testing - start TCWG-238

11 years, 7 months

1
0
0 0

[ACTIVITY] 23 - 27 December 2013

by Omair Javaid

== Progress == * ARM Process Record made the changes pointed out in maintainers comments. [3/10] [TCWG-336] [TCWG-338] [TCWG-339] - Put the new bug fixes patches on hold as they can be sent in the same series.[TCWG-317] [TCWG-315] * Time off for setting up new office space. [4/10] - Found a good room for office in a central location, need to get internet and other stuff working before shifting. I will get started on that once I get the possession of the space next week. * Time off for Macau visa information [1/10] * 25th December Public Holiday [2/10] == Plan == * ARM Process Record: - Create new patches as per maintainers suggestions, incorporating bug fixes as separate patches in the list. - Test and send all patches upstream. * New office space setup, will be away from my desk for few hours.

11 years, 7 months

1
0
0 0

bad code generation on aarch64 in aarch64_output_mi_thunk

by Matthias Klose

Hi, seen in a segfault running the tests in the coinor-osi package, https://launchpad.net/bugs/1263576, both in saucy and trusty, version 0.106.4 and 0.106.5. Version 0.103 doesn't show the issue. both the 4.7 and 4.8 linaro branches show this behaviour, and trunk 20131121 (didn't build a newer one yet). William Grant tracked that down to a bug with very negative vcall_offsets in aarch64 multiple inheritance thunks. The example below has two consecutive thunks, with the second adding 263 instead of subtracting 264. aarch64_build_constant seems to not handle negative integers. He tried a quick gcc patch to avoid using aarch64_build_constant, and the coinor-osi tests succeed. 0000000000401ca4 <_ZTv0_n256_N1C2adEv>: 401ca4: f9400010 ldr x16, [x0] 401ca8: f8500211 ldr x17, [x16,#-256] 401cac: 8b110000 add x0, x0, x17 401cb0: 17fffff9 b 401c94 <_ZN1C2adEv> [...] 0000000000401cc4 <_ZTv0_n264_N1C2aeEv>: 401cc4: f9400010 ldr x16, [x0] 401cc8: d28020f1 mov x17, #0x107 // #263 401ccc: f8716a11 ldr x17, [x16,x17] 401cd0: 8b110000 add x0, x0, x17 401cd4: 17fffff8 b 401cb4 <_ZN1C2aeEv> Any chance for a quick 2013 review? Thanks, Matthias --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -2540,8 +2540,8 @@ addr = plus_constant (Pmode, temp0, vcall_offset); else { - aarch64_build_constant (IP1_REGNUM, vcall_offset); - addr = gen_rtx_PLUS (Pmode, temp0, temp1); + aarch64_add_constant (IP0_REGNUM, IP1_REGNUM, vcall_offset); + addr = temp0; } aarch64_emit_move (temp1, gen_rtx_MEM (Pmode,addr));

11 years, 7 months

1
0
0 0

[Activity] Dec 16-26

by Rob Savoye

== Progress == * Lots of little changes to the Jenkins configure files and Cbuildv2 so Jenkins can do a builds in a 32 bit chroot. (4/10) * Misc - meetings and misc tasks (2/10). * Helped with binutils & GCC releases. 4/10) * New Arndale Octa arrived. == Plan == * Get back to adding the neon intrinsics tests to the GCC testsuite. * More Jenkins hacking for 32bit chroot builds. * More hacking on binary release automation. * Review Kugan's benchmarking support in Cbuildv2. == Issues == * Loosing ssh access to many of the machines we work on is a problem... == Leave == * A bit complicated. On the road till Jan 13, offline some, mixed with some work days depending on the weather. Should have email access most nights.

11 years, 7 months

1
0
0 0

Binutils fails to build

by Venkataramanan Kumar

Hi All, I am getting a weird error while building binutils from http://cbuild.validation.linaro.org/snapshots/Latest/binutils-linaro-2.23.2… GCC version gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9) Ubuntu 13.10 Steps: 1) /work/sources/binutils/configure --target=aarch64-unknown-linux-gnu --prefix=/work/builds/gcc-fsf-trunk/tools --with-sysroot=/work/builds/gcc-fsf-trunk/sysroot-aarch64-unknown-linux-gnu 2) make (Snip) gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I/work/sources/binutils/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic /work/sources/binutils/libiberty/regex.c -o regex.o In file included from /work/sources/binutils/libiberty/regex.c:128:0: /usr/include/stdlib.h:510:35: error: expected ‘,’ or ‘;’ before ‘__attribute_alloc_size__’ __THROW __attribute_malloc__ __attribute_alloc_size__ ((2)) __wur; ^ make[2]: *** [regex.o] Error 1 make[2]: Leaving directory `/work/builds/gcc-fsf-trunk/obj-aarch64-unknown-linux-gnu/binutils/libiberty' (Snip) Can anyone point me what is going wrong here. regards, Venkat,

11 years, 7 months

1
0
0 0

[ANNOUNCE] Linaro binutils 2.24 2013.12 released

by Victor Chong

### About Linaro binutils Linaro binutils is a release of the GNU binutils with bug fixes and enhancements for ARM platforms. GNU binutils is a collection of tools including the ld linker and as assembler. ### Linaro binutils 2.24 2013.12 The Linaro Toolchain Working Group is pleased to announce the 2013.12 release of Linaro binutils 2.24. This release is based on the latest GNU binutils 2.24 stable branch, but with additional features and bug fixes. ### Additional Features * Support for GNU indirect functions ### Bug Fixes * Fixed miscalculation of GOTPLT offset for ifunc syms * Handle static links with ifunc correctly * Fixup IFUNC tests to work on all targets ### Source ### Release Tarball * https://releases.linaro.org/13.12/components/toolchain/binutils-linaro ### Development Tree * git://git.linaro.org/toolchain/binutils-gdb.git This release was built from the linaro_binutils-2_24-2013_12_release tag. ### 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` * Questions? [ask Linaro](http://ask.linaro.org/). * Interested in commercial support? inquire at [Linaro support](mailto:support@linaro.org)

11 years, 7 months

1
0
0 0

[ACTIVITY] Week 51

by Yvan Roux

== Issues == * none == Progress == * LRA on AArch32: o TCWG-343 : Make LRA the default for the ARM backend (8/10) - Validated and committed a fix from Vladimir for Thumb1 issues. - iWMMXT issue : Tried a fix without success, continue working on it. o TCWG-345 : Analyse performance of LRA for ARM. (0/10) - No progress this week. * Various meetings. (2/10) == Next == * Vacation

11 years, 8 months

1
0
0 0

[ACTIVITY] 16 - 19 December 2013

by Omair Javaid

== Progress == * Debugged and Fixed process record memory corruption problem. [TCWG-315][TCWG-317][8/10] * Sick Time off [2/10] == Plan == * Send patches for bug fixes and look into remaining arm-native gdb issues. * Respond to maintainer's suggestion on process record patches. * Public Holiday on 25th * Time off for setting up new office space.

11 years, 8 months

1
0
0 0

[Activity] 16-19 DEC 2013

by Venkataramanan Kumar

== Progress == * Libssp GCC patch Replied to Marcus comments on libssp machine description support for stack protect and test. Analyzed other ports implementations on clearing register that loaded canary value. Waiting for his feedback. * Pointer mangling Aarch64 glibc. Investigated mangling support and implemented a patch. Testing glibc test suites in V8 Foundation model is in progress. * Attend Linaro Tool chain status meeting. * Attend 1-1 with Christophe (Linaro). * Attend 1-1 with Matt (Linaro) . == Plan == - Pointer Guard support in Aarch64 glibc - Continue tesing Cbuildv2

11 years, 8 months

1
0
0 0

[ACTIVITY] Week 51

by Zhenqiang Chen

== Issues == * None. == Progress == * Rebase aarch64 build scripts to crosstool-ng upstream, test and send out the patch for community review (2/10). * Investigate https://ci.linaro.org/jenkins/job/openembedded-armv8b-rootfs/gcc_version=4.…. It seams build configure issue. Some MICRO is not correctly defined. Can not follow-up it due to no access to the build system. * Continue on "uninit warning testsuite failures" (CARD 304 7/10) - Identify another reason why uninit-pred-8_b.c FAIL: The control flow is too complex, it can not normalize the condition at line 22 to ( n < 10 || m > 100 || r < 10 ). - Work on patch to fix PHI issue to make uninit-pred-9_b.c PASS. * Test builds for backporting "ftruncate() and truncate() stubs" related patches in Linaro newlib. == Plan == * Linaro toolchain binaries 2013.12 release.

11 years, 8 months

2
2
0 0

[ACTIVITY] 16-20 December 2013

by Kugan

== Progress == - Integrate benchmarking into Cbuildv2 (TCWG-360 7/10) - Implementation mostly complete - Started testing to ensure compatible with cbuild1 - Code available for comments at https://git.linaro.org/toolchain/cbuild2.git/shortlog/refs/heads/benchmarki… - Binutils Bug 16340 (1/10) - Posted the patch after regression testing and analysing the results - Mics (2/10) - Read relocation handling of tls and its implementation for aarch64 == Plan == - Complete Integrate benchmarking into Cbuildv2 - Address comments for Binutils Bug 16340 and look to come up with a simple testcase

11 years, 8 months

1
0
0 0

[ACTIVITY] Week 51

by Renato Golin

== Progress == * Android LLVM - Discussions on progress, trying to line up kernel+AOSP together - Google has bailed Clang/LLVM for L release, will consider for next one * Vectorizer - Progressing on the implementation of the pragma parser - http://llvm.org/PR18086 - Discussions about introduction of generic function vectorizer (ARM) * Release 3.4 - Tested RC3, no regressions on tests or benchmarks - http://people.linaro.org/~rengolin/llvm/ - http://llvm.org/pre-releases/3.4/rc3/ - Looked at a bug on the vectorizer for pentium3/freebsd - Work around found, not easy enough to get them to RC4 * Background - Many discussions, many support requests, many patch reviews - Adding BOF notes to dev meeting site - Booking train and hotel for FOSDEM 14 * Time - CARD-862 8/10 - Others 2/10 * Happy Holidays! And see you in January! == Issues == * Running benchmarks on my Chromebook is very unstable. - Even though the standard deviation is small in two different moments, the two results are statistically incompatible. - The wireless network on the Chromebook, as widely known, is unstable and unpredictable. - I need a graphical interface, so I can do stuff during Connects, or to see Phoronix results and that is probably the responsible for all instability - Next release, I'll use an ODroid (or Arndale) for benchmarks == Plan == * Holidays!

11 years, 8 months

1
0
0 0

[ACTIVITY] 16-20 December 2013

by Christophe Lyon

== Progress == - 2013.12 releases (4/10) * Handover to Michael * Committed remaining backports/branch merges * Unexpected regression in 4.7 branch narrowed to a linker bug, now fixed. - cross validations (2/10) * stabilized armeb+qemu validations - misc (4/10): misc conf-calls and meetings; internal meetings == Next == Next 2 weeks off (Dec 23rd Jan 3rd) Merry Christmas and happy new year to all of you.

11 years, 8 months

1
0
0 0

ARM vs THUMB builds

by Parimala Baggiri

Hello, I am using the pre-built toolchain gcc-arm-none-eabi-4_6-2012q2 from linaro to compile u-boot (u-boot-linaro-stable) and to compile my standalone applications to run on target(PandaBoard ES rev b2) hello_world standalone application which comes with u-boot is executing fine on target when I disable CONFIG_SYS_THUMB_BUILD, but when I enable it, target gets reset with following information Panda # go 82000000 hello ## Starting application at 0x82000000 ... undefined instruction pc : [<8200000c>] lr : [<bff83147>] sp : bfeffe40 ip : bfeffc10 fp : 00000000 r10: 00000003 r9 : bffac954 r8 : bfefff68 r7 : bff01d88 r6 : 82000000 r5 : bff01d8c r4 : 00000003 r3 : 82000000 r2 : bff01d8c r1 : bff01d8c r0 : 00000002 Flags: nzCv IRQs off FIQs off Mode SVC_32 Resetting CPU ... resetting ... U-Boot SPL 2013.01.-rc1-g0f45941 (Dec 17 2013 - 14:23:41) OMAP4460 <http://www.ti.com/product/OMAP4460> ES1.1 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.bin reading u-boot.bin ...... Can anyone please help me why thumb mode build is failing?

11 years, 8 months

3
6
0 0

Re: MMU Off / Strict Alignment

by Richard Earnshaw

On 18/12/13 05:06, Jonathan S. Shapiro wrote: > At the risk of sticking my nose in, this isn't a startup code issue. > It's a contract issue. > > First, I don't buy Richard's argument about memcpy() startup costs and > hard-to-predict branches. We do those tests on essentially every > *other* RISC platform without complaint, and it's very easy to order > those branches so that the currently efficient cases run well. Perhaps > more to the point, I haven't seen anybody put forward quantitative > data that using the MMU for unaligned references is any better than > executing those branches. Speaking as a recovering processor > architect, that assumption needs to be validated quantitatively. My > guess is that the branches are faster if properly arranged. > > Second, this is a contract issue. If newlib intends to support > embedded platforms, then it needs to implement algorithms that are > functionally correct without relying on an MMU. By all means use > simpler or smarter algorithms when an MMU can be assumed to be > available in a given configuration, but provide an algorithm that is > functionally correct when no MMU is available. "Good overall > performance in memcpy" is a fine thing, but it is subject to the > requirement of meeting functional specifications. As Jochen Liedtke > famously put it (read this in a heavy German accent): "Fast, ya. But > correct? (shrug) Eh!" > > So: we need a normative statement saying what the contract is. The > rest of the answer will fall out from that. > > I do agree with Richard that startup code is special. I've built > deeply embedded runtimes of one form or another for 25 years now, and > I have yet to see a system where optimizing a simplistic byte-wise > memcpy during bootstrap would have made any difference in anything > overall. That said, if the specification of memcpy requires it to > handle incompatibly aligned pointers (and it does), and the contract > for newlib requires it to operate in MMU-less scenarios in a given > configuration (which, at least in some cases, it does), it's > completely legitimate to expect that bootstrap code can call memcpy() > and expect behavior that meets specifications. > > So what's the contract? > I disagree with your assertion that newlib *requires* it to operate in an MMU-less scenario for all targets; it only does so when the target can reasonably be expected to not have an MMU. The only contract that exists is the one written in the C standard: 7.23.2.1#2 The memcpy function copies n characters from the object pointed to by s2 into the object pointed to by s1. If copying takes place between objects that overlap, the behavior is undefined. But that is written on the assumption that we're in a normal execution environment, not in some special case. What you're missing is that AArch64 is (in ARM ARM terms) an A-profile only environment where an MMU is mandated in the system. Furthermore, processors implementing the architecture will *expect* that the MMU be turned on as soon as possible after boot, since without this the caches cannot be used and without those the performance will be truly horrible. Once the caches are enabled, it's perfectly reasonable to assume that memcpy will only be used for copies to and from NORMAL memory, since other types of memory have potential side effects, which means that use of memcpy would be unsafe. If you want to write an MMU-less memcpy, then feel free to write one; but please install it with a different interface -- something like __memcpy_nommu(). Don't penalise the standard case for the non-standard exceptional one. R.

11 years, 8 months

1
0
0 0

segfault using __thread variable

by Michael Hudson-Doyle

Hi all, I have a bit of a strange one. I'm not after a full solution, just any hints that quickly come to mind :) After a few simple patches I have a build of mongodb for aarch64 (built with gcc-4.8). However, all of the test binaries that the build spits out immediately segfault. gdb-ing shows that they segfault inside this macro: TSP_DECLARE(OwnedOstreamVector, threadOstreamCache); This expands to: # define TSP_DECLARE(T,p) \ extern __thread T* _ ## p; \ template<> inline T* TSP<T>::get() const { return _ ## p; } \ extern TSP<T> p; And indeed, it's mongo::TSP<mongo::OwnedPointerVector<...> >::get() const that we're segfaulting in. This is the disassembly of this function (at -O0) with the faulting instruction marked: 0x00000000004b4b6c <+0>: stp x29, x30, [sp,#-32]! 0x00000000004b4b70 <+4>: mov x29, sp 0x00000000004b4b74 <+8>: str x0, [x29,#16] 0x00000000004b4b78 <+12>: adrp x0, 0x64c000 0x00000000004b4b7c <+16>: ldr x0, [x0,#776] 0x00000000004b4b80 <+20>: nop 0x00000000004b4b84 <+24>: nop 0x00000000004b4b88 <+28>: mrs x1, tpidr_el0 0x00000000004b4b8c <+32>: add x0, x1, x0 => 0x00000000004b4b90 <+36>: ldr x0, [x0] 0x00000000004b4b94 <+40>: ldp x29, x30, [sp],#32 0x00000000004b4b98 <+44>: ret And the registers: (gdb) info registers x0 0x7fb863fd70 548554407280 x1 0x7fb7ff76f0 548547819248 x2 0x0 0 x3 0x7fb7fc11b8 548547596728 x4 0x1 1 x5 0x0 0 x6 0x50 80 x7 0x0 0 x8 0x0 0 x9 0x6165727473676f4c 7018141438804717388 x10 0x0 0 x11 0x0 0 x12 0x2 2 x13 0x10 16 x14 0x0 0 x15 0x7fb7e5e590 548546143632 x16 0x64b3d8 6599640 x17 0x7fb7f667d0 548547225552 x18 0x7fffffdab0 549755804336 x19 0x7fffffed50 549755809104 x20 0xb 11 x21 0xb 11 x22 0x6500b0 6619312 x23 0x650070 6619248 x24 0x7fffffff 2147483647 x25 0x64db40 6609728 x26 0x7fffffeda0 549755809184 x27 0x653d00 6634752 x28 0x7fffffe750 549755807568 x29 0x7fffffe4d0 549755806928 x30 0x4b4ed4 4935380 sp 0x7fffffe4d0 0x7fffffe4d0 pc 0x4b4b90 0x4b4b90 <mongo::TSP<mongo::OwnedPointerVector<std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> > > >::get() const+36> cpsr 0x20000000 536870912 fpsr 0x0 0 fpcr 0x0 0 If I recompile this object file without -fPIC, it works. I guess I see three things that could be wrong: 1) The operand to "adrp x0, 0x64c000"[1] 2) The operand to "ldr x0, [x0,#776]" 3) The value of tpidr_el0 Oh, and I guess: 4) The setup of tls has gone wrong and the address in x0 _ought_ to be accessible but isn't for some reason. Any hints on which of these seems mostly likely to be the culprit? Chers, mwh [1] FWIW, objdump reports 0x64c000 as "_GLOBAL_OFFSET_TABLE_+0x2d0", not sure why that doesn't show up in gdb's disassembly).

11 years, 8 months

5
20
0 0

[ACTIVITY] Week 51

by Will Newton

== Progress == * Bugfixing and testing QEMU AArch64 FP patches (3/10, VIRT-183) * Debugging and submitting a patch for ARM gdb ifunc test failures (1/10) * Two day week due to holidays == Issues == * None == Plan == * Back on the 9th January, have a good Christmas and New Year everybody! -- Will Newton Toolchain Working Group, Linaro

11 years, 8 months

1
0
0 0

MMU Off / Strict Alignment

by Christopher Covington

Hi, We've noticed an issue trying to use the Linaro AArch64 binary bare metal toolchain release with the MMU turned off for some low-level tests. Anytime puts, sprintf, etc. gets called, a reent structure gets created with references to STDIN, STDOUT, STDERR FILE types. A member in the __sFile struct, _mbstate, is an 8 byte struct, but is not aligned on an 8 byte boundary. This means that when memset (or a similar function) gets called on this struct, and doesn't operate one byte at a time, a data alignment fault will be generated when operating out of device memory, such as on a system where the MMU has not yet been turned on yet. I'm still examining possible fixes (I'll probably look at building with -mstrict-align first), but I wanted to check if anyone had thoughts on the subject and if Newlib upstream or Linaro consider using Newlib with the MMU turned off to be a valid use case or if running the code that turns on the MMU is considered a prerequisite to everything else. Thanks, Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation.

11 years, 8 months

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain