linaro-toolchain

linaro-toolchain@lists.linaro.org

6 participants
5578 discussions

by Yvan Roux

== Progress == o Linaro GCC/Validation (7/10) - Reviewed on-going Backports. - Analysis on remaining backports dependencies on-going. - Merged FSF GCC 6 branch. - Last FSF GCC 4.9 merge still on-going (some conflicts to solve). - Defining and experimenting new revisions/backports tracking format in yaml. o Misc (3/10) * Various meetings and discussions. == Plan == o FInish backports, and FSF branch merge for next week snapshot.

8 years, 8 months

[ACTIVITY] 22 - 26 August 2016

by Prathamesh Kulkarni

== This Week == * TCWG-666 (2/10) - Martin confirmed the assert was spurious that caused some obj-c tests to fail, removing it passes bootstrap+test. - Changed option name to -fipa-bit-cp following Honza's suggestion - Committed as r239769. * TCWG-779 (4/10) - Patch iterations based on upstream suggestions. * Public Holiday (2/10) * Misc (2/10) - Background reading on mod/ref analysis - Meetings

8 years, 8 months

[ACTIVITY] 22 - 26 August 2016

by Yao Qi

# Progress # * TCWG-685, GDB 7.12 release. [4/10] Finish all native testing on ARM. Triaged tests result. Only find one fail that test assumes HW watchpoint is always available. Reported it upstream, but need more thoughts on how to fix it. Both AArch64 and ARM GDB is in a good state, in terms of test results. * TCWG-533, Remove global variable arm_override_mode. [2/10] It is paused by 7.12 release, and work on it again. 10 patches are ready. Being regression tested. * Analyse the kernel behaviour on single step over fork. [4/10] Upgrade juno kernel to 4.7.0-rc4+, and verified Will Deacon's patch. http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/451711.ht… With the patch, GDB can correctly single step over fork, however, GDB is still broken if there is a breakpoint. Write a small reproducer, but doesn't trigger the problem. It might be a GDB bug or kernel bug. # Plan # * Resume works interrupted by 7.12 release. -- Yao Qi

8 years, 8 months

[ACTIVITY] 22 - 26 August 2016

by Peter Smith

== Progress == - Got back from Sabbatical and caught up with email/events - TCWG-610 Support for ARM Exceptions in lld. Implemented support for SHF_LINK_ORDER and .ARM.exidx in lld, have this working and tested for images (both with default and linker scripts) and relocatable ld -r with the default layout. Currently it looks like relocatable outputs with linker scripts aren't working at all right now. == Plan == - Hope to send to upstream review next week. - Write the first pass of the LLVM Cauldron presentation. == Planned absence == Monday 29th August is UK national holiday

8 years, 8 months

[ACTIVITY] 22 - 26 August 2016

by Diana Picus

== Progress == * [AArch64] Support for label arithmetic in the assembler [TCWG-710] [9/10] - Patch in upstream review - While adding more tests for the patch above, I noticed that we're not encoding the lsl #12 on add/sub immediates correctly - Submitted a patch to fix that as well * Misc [1/10] - Ran more precommit tests for last week's reverted revisions == Plan == * Handle special cases in AArch64InstrInfo::GetInstSizeInBytes [TCWG-757]

8 years, 8 months

[ACTIVITY] 15 - 19 Aug

by Yao Qi

* Two days off [4/10] # Progress # * TCWG-685, GDB 7.12 release. [3/10] Fix one bug that AArch64 GDB doesn't recognize new "STP with base register" instruction in prologue. Recent GCC https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01933.html starts to generate that instruction in prologue. Fix it in both master and 7.12. Successfully build armhf toolchain with latest gcc/glibc. Run GDB tests with the new toolchain. Test results are OK, except fails when tests are compiled with -march=cortex-a15. It isn't a release blocker. Open TCWG-756 for it and will look into these fails later. * GDBserver build failure. [1/10] Review the patch fixing GDBserver build failure with latest glibc. Patch is OK, but make sure it can be merged to master/7.12/7.11, as we are still using GDB 7.11. * Prelink. [1/10] prelink causes some GDB tests failures, so I look at it. prelink isn't active, because I can't see any mails in archive since 2013. ARM is supported, but AArch64 isn't. * Misc, [1/10]. Set up email 2fa. # Plan # * GDB 7.12 release. * Upgrade the linux kernel on my juno board. -- Yao Qi

8 years, 9 months

[ACTIVITY] 15 - 19 August 2016

by Diana Picus

== Progress == * LLVM 3.9.0 Release for AArch64 [TCWG-696] [1/10] - Ran the tests for RC2, everything looks good on AArch64 * [AArch64] Support for label arithmetic in the assembler [TCWG-710] [3/10] - This is starting to look like a patch, but I need to add more tests * Buildbot babysitting [TCWG-716, 719, 720] [5/10] - Bisected a number of failures and reverted some patches - Ran precommit tests for 2 different issues; one of them has passed with the author's fix, the other one hasn't, so I'll probably have to help figure out what the problem is * Set up a BeagleBoard so I can run some tests for TCWG-674 [1/10] == Plan == * [AArch64] Support for label arithmetic in the assembler [TCWG-710] - Send a patch upstream * Run more precommits if necessary

8 years, 9 months

[ACTIVITY] Week 33

by Yvan Roux

o one day off (2/10) == Progress == o Linaro GCC/Validation (3/10) - Continuing Backports. - Prepared branch merges - AArch64 builders stable again after Jenkins upgrade. - Investigated GDB build failure with Glibc trunk, Adhemerval patch accepted upstream. - start to merge Bkk16-buildfarm job into main buildfarm one. o Upstream GCC (1/10) - Guality fix: more investigation . o Misc (4/10) * Various meetings and discussions. * Another Internal support. == Plan == o Continue on backports, and FSF branch merge, etc

8 years, 9 months

gcc-linaro-6.1-2016.07...Big Endian and Little Endian aarch64 Options

by stimits＠comcast.net

Hi, I was able to get linaro-6.1-2016.07 compiled for both aarch64 and armhf. I also have some prebuilt 5.2 and 5.3 binaries, plus a few other 4.8 and 4.9 compilers from quite some time back. I've used these for building a Linux 3.10 kernel, and the newer linaro-6.1 fails during kernel compile. The issue seems to be the assembler does not recognize option "-EL" (all of the ARM systems I'm building for are little endian, I've not seen a big endian system). I am wondering if support for options "-EB" and "-EL" are part of the configure options? There is the generic "help" listing the "--enable-FEATURE=ARG", but I do not see a comprehensive list of features this might deal with. I'm hoping that big/little endian for armhf and aarch64 can be enabled with this. Otherwise I'm hoping to find more information on what I might need to do or change for compatibility with the "-EL" option. For reference, I have similar templates for 32-bit and 64-bit configuration (different triplet and build root). Here's one: export SRC='/home/build/linaro/gcc-linaro-snapshot-6.1-2016.07'export BUILD='/home/build/linaro/32bit'export TRIPLET=arm-linux-gnueabihfexport CLONE=/usr/local/sysroot/${TRIPLET}export VENDOR_ID=gcc-linaro-6.1-2016.07export LINUX_ARCH=armhf cd $BUILD${SRC}/configure --prefix=/usr/local/${TRIPLET}/${VENDOR_ID} --target=${TRIPLET} \ --with-build-sysroot=${CLONE} \ --enable-languages=c \ --with-sysroot=/ Thanks!

8 years, 9 months

gcc-linaro-snapshot-6.1-2016.07 Sysroot/Host Requirements Question

by stimits＠comcast.net

Hi, In a previous thread some sysroot issues were resolved, and I am able to build cross-compilers under gcc-linaro-snapshot-6.1-2016.07 for languages c, c++, and objc. My sysroot consisted of a loopback mounted dd copy of an Ubuntu 14.04 file system for aarch64. That particular file system runs on a quad core Cortex-A57, and is fully capable of compiling many different types of software (the file system is set up for development). The successful configuration was like this (configuration and compile was from an independent directory not in the source tree): export SRC='/home/build/linaro/gcc-linaro-snapshot-6.1-2016.07'export TRIPLET=aarch64-linux-gnuexport CLONE=/usr/local/sysroot/${TRIPLET}export VENDOR_ID=gcc-linaro-6.1-2016.07export LINUX_ARCH=arm64 ${SRC}/configure --prefix=/usr/local/${TRIPLET}/${VENDOR_ID} --target=${TRIPLET} \ --with-build-sysroot=${CLONE} \ --enable-languages=c,c++,objc \ --with-sysroot=/ Now I also need armhf (I must support both 32-bit and 64-bit), so I'm trying to figure out host and sysroot differences (I have been unable to get armhf to compile). The configuration is basically this variation of the above, plus some sysroot additional support: export SRC='/home/build/linaro/gcc-linaro-snapshot-6.1-2016.07'export TRIPLET=arm-linux-gnueabihfexport CLONE=/usr/local/sysroot/${TRIPLET}export VENDOR_ID=gcc-linaro-6.1-2016.07export LINUX_ARCH=armhf ${SRC}/configure --prefix=/usr/local/${TRIPLET}/${VENDOR_ID} --target=${TRIPLET} \ --with-build-sysroot=${CLONE} \ --enable-languages=c \ --with-sysroot=/ Note that for testing purposes I tried to compile only languages of c, c++, and objc, each one at a time instead of together. Errors do not differ in any way for picking of any of those three languages. I also have a complete Ubuntu 14.04 file system for armhf which is fully equipped for building of each of those languages, and is perhaps in some ways more complete as a development environment than the previously successful aarch64 file system (the sysroot runs on a quad core Cortex-A15). I tried this purely armhf file system as the sysroot to rule out incorrect multiarch support, and the error did not change. I am guessing the issue is not the sysroot, but I wanted to verify this since there may be other requirements for armhf instead of aarch64. I am at a loss though to explain why the host would be at issue since it appears all prerequisites were met and I had success with aarch64. The details of the error seem to always occur in libcc1 build. I see this in the libcc1/config.log as the failure regardless of sysroot or supported language, and only while building for armhf: configure:14569: checking for -rdynamicconfigure:14579: result: yesconfigure:14589: checking for library containing dlopenconfigure:14620: gcc -o conftest -g -O2 conftest.c >&5/tmp/ccyhVkpp.o: In function `main':/home/build/linaro/objdir/libcc1/conftest.c:38: undefined reference to `dlopen'collect2: error: ld returned 1 exit statusconfigure:14620: $? = 1configure: failed program was:| /* confdefs.h */| #define PACKAGE_NAME "libcc1"| #define PACKAGE_TARNAME "libcc1"| #define PACKAGE_VERSION "version-unused"| #define PACKAGE_STRING "libcc1 version-unused"| #define PACKAGE_BUGREPORT ""| #define PACKAGE_URL ""| #define STDC_HEADERS 1| #define HAVE_SYS_TYPES_H 1| #define HAVE_SYS_STAT_H 1| #define HAVE_STDLIB_H 1| #define HAVE_STRING_H 1| #define HAVE_MEMORY_H 1| #define HAVE_STRINGS_H 1| #define HAVE_INTTYPES_H 1| #define HAVE_STDINT_H 1| #define HAVE_UNISTD_H 1| #define __EXTENSIONS__ 1| #define _ALL_SOURCE 1| #define _GNU_SOURCE 1| #define _POSIX_PTHREAD_SEMANTICS 1| #define _TANDEM_SOURCE 1| #define HAVE_DLFCN_H 1| #define LT_OBJDIR ".libs/"| #define HAVE_DECL_BASENAME 1| /* end confdefs.h. */ Are there different host requirements when building armhf versus aarch64 which might explain why dlopen is not found? FYI, both development and other support for dlopen exists already on the system, so the failure to find dlopen is not for lack of host support (related dlopen files all seem to be present on all tested sysroots as well, both as armhf and aarch64). Is this a sysroot issue, a host issue, or a configure issue? Thanks!

8 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain