linaro-toolchain March 2014

linaro-toolchain@lists.linaro.org

31 participants
41 discussions

[ANNOUNCE] Linaro GCC 4.8 2014.03 released

by Yvan Roux

The Linaro Toolchain Working Group is pleased to announce the 2014.03 engineering release of Linaro GCC 4.8. As announced at Linaro Connect USA 2013 Linaro GCC is moving to a pattern of quarterly stable releases, with engineering releases in the intervening months. This is the second engineering release. The next stable release will be the 2014.04 release. Linaro GCC 4.8 2014.03 is the twelfth release in the 4.8 series. Based off the latest GCC 4.8.3+svn208264 release, it includes performance improvements and bug fixes. Interesting changes include: * Updates to GCC 4.8.3+svn208264 The source tarball is available from: http://releases.linaro.org/14.03/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 page: https://launchpad.net/gcc-linaro/4.8/4.8-2014.03 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 ~

10 years, 8 months

[ACTIVITY] Week 11

by Renato Golin

== Progress == * Ill until Thusrday due to Chinese food allergy/intolerance/poisoning - Seems I'm not the only one... * EHABI - Adding a few more EH tests to test-suite - Integration with ARM compiler better handled by ARM - Plugging -fno-unwind-tables to disable EH tables in ARM * Android - Implementing __builtin___clear_cache in LLVM - Need to add parsing to Clang later, and docs to LangRef * AArch64 - Tested a "fix" on sphereflake, didn't work - Seems the problem is the sin() results on glibc variants - We might need to round the result a bit shorter to make it work everywhere * Time - CARD-862 8/10 - Others 2/10 == Plan == * Continue ___builtin__clear_cache implementation * Continue RT and AArch64 test-suite investigation

10 years, 8 months

build errors

by JustinGuo＠via-alliance.com

Dear Linaro toolchain support team: I am Justin Guo from S3 graphics Inc. I am studying linaro's big-little codes and is using TC2 Platform. I used ./linaro_kernel_build_cmds.sh to build kernel, I got no problem when I set CONFIG_DEBUG_INFO=y to build for kernel. However, When I trace kernel, the traced line in source code level is jumping up/down, so I tried to turn off the optimization. After modified Makefile as below to turn off optimization: ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,) else KBUILD_CFLAGS += -O0 endif I got errors when build linaro kernel for TC2: root@ubuntu:/home/justinguo/linaro/1309# ./linaro_kernel_build_cmds.sh Directory linaro-kernel exists. If the kernel code exists in this directory you may continue without cloning the git repository for the kernel. Are you sure you want to do this? (y/n) y M Makefile HEAD is now at dafe325... Merge branch 'linux-linaro-lsk' into linux-linaro-lsk-android % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 57281 100 57281 0 0 90703 0 --:--:-- --:--:-- --:--:-- 188k Using /home/justinguo/linaro/1309/linaro-kernel as source for kernel GEN /home/justinguo/linaro/1309/linaro-kernel/out/Makefile CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h make[2]: `include/generated/mach-types.h' is up to date. CC kernel/bounds.s GEN include/generated/bounds.h CC arch/arm/kernel/asm-offsets.s GEN include/generated/asm-offsets.h CALL /home/justinguo/linaro/1309/linaro-kernel/scripts/checksyscalls.sh CC scripts/mod/empty.o MKELF scripts/mod/elfconfig.h CC scripts/mod/devicetable-offsets.s GEN scripts/mod/devicetable-offsets.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost CC init/main.o CHK include/generated/compile.h CC init/version.o CC init/do_mounts.o CC init/do_mounts_rd.o CC init/do_mounts_initrd.o LD init/mounts.o CC init/initramfs.o CC init/calibrate.o CC init/init_task.o LD init/built-in.o CC arch/arm/vfp/vfpmodule.o AS arch/arm/vfp/entry.o AS arch/arm/vfp/vfphw.o CC arch/arm/vfp/vfpsingle.o CC arch/arm/vfp/vfpdouble.o LD arch/arm/vfp/vfp.o LD arch/arm/vfp/built-in.o CC arch/arm/kernel/elf.o AS arch/arm/kernel/entry-armv.o AS arch/arm/kernel/entry-common.o CC arch/arm/kernel/irq.o CC arch/arm/kernel/opcodes.o CC arch/arm/kernel/process.o CC arch/arm/kernel/ptrace.o CC arch/arm/kernel/return_address.o /home/justinguo/linaro/1309/linaro-kernel/arch/arm/kernel/return_address .c:63:2: warning: #warning "TODO: return_address should use unwind tables" [-Wcpp] CC arch/arm/kernel/sched_clock.o CC arch/arm/kernel/setup.o CC arch/arm/kernel/signal.o CC arch/arm/kernel/stacktrace.o CC arch/arm/kernel/sys_arm.o CC arch/arm/kernel/time.o CC arch/arm/kernel/traps.o CC arch/arm/kernel/atags_parse.o CC arch/arm/kernel/cpuidle.o CC arch/arm/kernel/armksyms.o CC arch/arm/kernel/module.o AS arch/arm/kernel/sleep.o CC arch/arm/kernel/suspend.o CC arch/arm/kernel/smp.o CC arch/arm/kernel/smp_tlb.o CC arch/arm/kernel/smp_scu.o CC arch/arm/kernel/smp_twd.o CC arch/arm/kernel/arch_timer.o CC arch/arm/kernel/ftrace.o CC arch/arm/kernel/insn.o CC arch/arm/kernel/unwind.o CC arch/arm/kernel/devtree.o CC arch/arm/kernel/swp_emulate.o CC arch/arm/kernel/hw_breakpoint.o CC arch/arm/kernel/perf_event.o CC arch/arm/kernel/perf_event_cpu.o CC arch/arm/kernel/topology.o CC arch/arm/kernel/io.o CC arch/arm/kernel/psci.o /tmp/cciaYmCJ.s: Assembler messages: /tmp/cciaYmCJ.s:147: Error: .err encountered /tmp/cciaYmCJ.s:148: Error: .err encountered /tmp/cciaYmCJ.s:149: Error: .err encountered /tmp/cciaYmCJ.s:150: Error: .err encountered /tmp/cciaYmCJ.s:191: Error: .err encountered /tmp/cciaYmCJ.s:192: Error: .err encountered /tmp/cciaYmCJ.s:193: Error: .err encountered /tmp/cciaYmCJ.s:194: Error: .err encountered make[2]: *** [arch/arm/kernel/psci.o] Error 1 make[1]: *** [arch/arm/kernel] Error 2 make: *** [sub-make] Error 2 root@ubuntu:/home/justinguo/linaro/1309# Could you Please help fix these issues? Best regards, Justin Guo

10 years, 8 months

Call for testing QEMU aarch64-linux-user emulation

by Alex Bennée

Hi, After a solid few months of work the QEMU master branch [1] has now reached instruction feature parity with the suse-1.6 [6] tree that a lot of people have been using to build various aarch64 binaries. In addition to the SUSE work we have fixed numerous edge cases and finished off classes of instructions. All instructions have been verified with Peter's RISU random instruction testing tool. I have also built and run many packages as well as built gcc and passed most of the aarch64 specific tests. I've tested against the following aarch64 rootfs: * SUSE [2] * Debian [3] * Ubuntu Saucy [4] In my tree the remaining insns that the GCC aarch64 tests need to implement are: FRECPE FRECPX CLS (2 misc variant) CLZ (2 misc variant) FSQRT FRINTZ FCVTZS Which I'm currently working though now. However for most build tasks I expect the instructions in master [1] will be enough. If you want the latest instructions working their way to mainline you are free to use my tree [5] which currently has: * Additional NEON/SIMD instructions * sendmsg syscall * Improved helper scripts for setting up binfmt_misc * The ability to set QEMU_LOG_FILENAME to /path/to/something-%d.log - this is useful when tests are failing N-levels deep as %d is replaced with the pid Feedback I'm interested in ========================== * Any instruction failure (please include the log line with the unsupported message) * Any aarch64 specific failures (i.e. not generic QEMU threading flakeiness). If you need to catch me in real time I'm available on #qemu (stsquad) and #linaro-virtualization (ajb-linaro). Many thanks to the SUSE guys for getting the aarch64 train rolling. I hope your happy with the final result ;-) Cheers, -- Alex Bennée QEMU/KVM Hacker for Linaro [1] git://git.qemu.org/qemu.git master [2] http://download.opensuse.org/ports/aarch64/distribution/13.1/appliances/ope… [3] http://people.debian.org/~wookey/bootstrap/rootfs/debian-unstable-arm64.tar… [4] http://people.debian.org/~wookey/bootstrap/rootfs/saucy-arm64.tar.gz [5] https://github.com/stsquad/qemu/tree/ajb-a64-working [6] https://github.com/susematz/qemu/tree/aarch64-1.6

10 years, 8 months

linking AArch64 ELF image with aarch64-linux-gnu-ld yields RELASZ = 0

by Claudio Fontana

Hello, I am building an ELF image using aarch64-linux-gnu-ld from linaro: GNU ld (crosstool-NG linaro-1.13.1-4.8-2014.02 - Linaro GCC 2014.02) 2.24.0.20131220 I am linking in the libstc++.a, which contains in particular a GOT entry for __gthread_active_ptr that is of interest to me, pointing to __pthread_key_create, used for detecting pthread support for std::thread, and while I get the relocations for the GOT itself in a .rela.dyn section, and a nice pointer to it from the dynamic section (RELA), the dynamic RELASZ entry contains zero: Here is the comparison of the Dynamic section (note RELASZ) with the following .rela.dyn relocations: loader.elf: file format elf64-littleaarch64 loader.elf architecture: aarch64, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x00000000400b0000 Program Header: LOAD off 0x0000000000000000 vaddr 0x0000000040090000 paddr 0x0000000040090000 align 2**16 filesz 0x0000000000407084 memsz 0x00000000004aa504 flags rwx TLS off 0x0000000000407080 vaddr 0x0000000040497080 paddr 0x0000000040497080 align 2**3 filesz 0x0000000000000004 memsz 0x0000000000000580 flags rw- DYNAMIC off 0x0000000000001000 vaddr 0x0000000040091000 paddr 0x0000000040091000 align 2**3 filesz 0x0000000000000120 memsz 0x0000000000000120 flags rw- EH_FRAME off 0x00000000003ce5fc vaddr 0x000000004045e5fc paddr 0x000000004045e5fc align 2**2 filesz 0x000000000000bae4 memsz 0x000000000000bae4 flags r-- NOTE off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**3 filesz 0x0000000000000000 memsz 0x0000000000000000 flags --- Dynamic Section: NEEDED dummy-shlib.so INIT_ARRAY 0x00000000404841b8 INIT_ARRAYSZ 0x0000000000000330 HASH 0x000000004044bd58 STRTAB 0x00000000403e3320 SYMTAB 0x00000000403a4110 STRSZ 0x0000000000068a33 SYMENT 0x0000000000000018 DEBUG 0x0000000000000000 RELA 0x00000000404780c0 RELASZ 0x0000000000000000 RELAENT 0x0000000000000018 private flags = 0: ... 10 .rela.dyn 00002058 00000000404780c0 00000000404780c0 003e80c0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA ... and now the .rela.dyn.relocations from aarch64-linux-gnu-readelf -r loader.elf : Relocation section '.rela.dyn' at offset 0x3e80c0 contains 345 entries: Offset Info Type Sym. Value Sym. Name + Addend 0000404832d0 002b00000401 R_AARCH64_GLOB_DA 00000000405339c8 _ZNSt8time_getIwSt19is + 0 0000404832d8 004400000401 R_AARCH64_GLOB_DA 000000004047e450 _ZTISt7codecvtIcc11__m + 0 0000404832e0 004b00000401 R_AARCH64_GLOB_DA 00000000405338c8 _ZGVNSt8numpunctIcE2id + 0 0000404832e8 005800000401 R_AARCH64_GLOB_DA 000000004047c460 _ZTISt8messagesIcE + 0 0000404832f0 006200000401 R_AARCH64_GLOB_DA 000000004047df40 _ZTVSt9strstream + 0 0000404832f8 007200000401 R_AARCH64_GLOB_DA 00000000402870dc _ZNSt17bad_function_ca + 0 000040483300 008500000401 R_AARCH64_GLOB_DA 0000000040534e58 _ZGVN9__gnu_cxx16bitma + 0 000040483310 00c300000401 R_AARCH64_GLOB_DA 0000000040533a18 _ZNSt6locale2id11_S_re + 0 000040483318 00dd00000401 R_AARCH64_GLOB_DA 000000004047c160 _ZTISt5ctypeIwE + 0 000040483320 00ea00000401 R_AARCH64_GLOB_DA 0000000040534e18 _ZZN9__gnu_cxx9free_li + 0 000040483328 011700000401 R_AARCH64_GLOB_DA 0000000040533968 _ZGVNSt8time_getIwSt19 + 0 000040483330 013500000401 R_AARCH64_GLOB_DA 000000004047cfd8 _ZTISt7num_getIwSt19is + 0 000040483338 017300000401 R_AARCH64_GLOB_DA 000000004021d51c __pthread_key_create + 0 ... ^^...note the __pthread_key_create relocation I am interested in... I would expect the RELASZ in the dynamic section to be 0x2058 instead of 0. Any tips to what could be wrong? Thank you, Claudio Fontana

10 years, 8 months

Building a native version of Linaro GCC in Ubuntu

by Felipe Rocha da Rosa

Hi, I'm trying to build the native compiler to a arm a9 using this tutorial,https://wiki.linaro.org/WorkingGroups/ToolChain/Using/GCCNative.Ho…, I need to compile in a x86_64 platform ubuntu, like this --target=arm-unknown-eabi --build=i686-pc-linux-gnu --host=arm-unknown-eabi, but without success.There is any possible solution? Thank you.Felipe Rocha da Rosa.

10 years, 8 months

Trouble executing ARM code on linaro toolchain

by Vishwanath C

Hi all, We are using Linaro 13.03 toolchain(gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux We are trying to execute a simple test code to check whether ARM assembly code executes on board or not. Execution is on Arndale Board. Every time We include assembly function, We get segmentation fault. Kindly check if I We are missing any arm related flags in makefile. We have attached the 'helloworld' test code and makefile. Regards, Vishwa =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. ===============================================================================

10 years, 8 months

RE: detecting the linaro toolchain via C/C++ preprocessor

by Vermeulen, Michiel

If your code is sensitive to the size of long long, can you use the predefine: __SIZEOF_LONG_LONG__ If that doesn't work, then you can use: gcc -dM -E - < /dev/null to tell you what predefines a gcc compiler has (I would probably look for predefines more specific to what your code is sensitive to than look for a particular compiler). I also wonder a little about your original problem statement since "%lld" should be a way to always print "long long" and if you have a matched set of compiler and library, then it should adjust both together. If you are using "%ld" instead, this works in situations where "long" is the same size as "long long" but may not work when these are different sizes. --mev, Mike Vermeulen

10 years, 8 months

detecting the linaro toolchain via C/C++ preprocessor

by Isidor Zeuner

Hi there! On Linaro gcc 4.6, I am facing an issue due to "long long" integers not being 64 bit as they are on other platforms I'm targeting, which causes different issues, most importantly with printf format strings. I am now circumventing these by using the C/C++ preprocessor in order to choose the right format strings. In order to minimize the necessity for users to manually configure things, I'm wondering if there is a way to detect the Linaro gcc compiler through preprocessor macros. Is this possible? Thanks. Best regards, Isidor

10 years, 8 months

Trouble executing ARM code on linaro toolchain

by Vishwa

10 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain March 2014