linaro-toolchain April 2011

linaro-toolchain@lists.linaro.org

29 participants
73 discussions

undefined reference to __aeabi_unwind_cpp_pr0

by AJ ONeal

I'm compiling an application built with TI's DVSDK 3 *[0]. /home/user/ti/dvsdk/dvsdk_3_01_00_10/linuxutils_2_25_02_08/packages/ti/sdo/linuxutils/cmem/lib/cmem.a470MV(cmem.o470MV):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1) 4.5.2 arm-linux-gnueabi-ld --version GNU ld (GNU Binutils for Ubuntu) 2.21.0.20110302 More full output is here (but it isn't particularly helpful due to TI's RTSC make system's black-magic) https://gist.github.com/925674 FYI: the MV in cmem.a470MV stands for MontaVista. This name is hard-coded somewhere even though it's not being linked against a MontaVista system. I believe the 470 means that it should work with ARMv4 through ARMv7, but I'm not positive. My googling suggest that this is a toolchain bug and that the best way around the issue is to create a file which defines the function as a void dummy and include it. http://www.codesourcery.com/archives/arm-gnu/msg03604.html http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/78649 http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=__aeabi_unwind_cpp_pr0 I have a script that I'll post shortly with instructions as to how to setup TI's DVSDK with Linaro AJ ONeal [0] I'm not using the latest DVSDK version 4 because the paths and such are so hard-coded for the 2009q3 version of codesourcery on ubuntu 10.04 LTS that I don't know where to start fixing it.

12 years, 6 months

Bug in linaros implementation of vset_lane intrinsics

by Lee Moore

Hi All, This is based upon gcc version 4.5.3 (20110221 pre-release) Any help appreciated This shows a bug in the Linaro gcc compiler with the Arm NEON vset_lane intrinsic Note in the objdump that the vmov.8 instruction that places the value in the vector for the non-q version uses 1 where it should use 2 and 3: 18: ee410bb0 vmov.8 d17[1], r0 1c: ee420bb0 vmov.8 d18[1], r0 20: ee400b90 vmov.8 d16[0], r0 3c: ee440bb0 vmov.8 d20[1], r0 For the q version the vmov.8 instructions are correct: 40: ee420bf0 vmov.8 d18[3], r0 54: ee420bd0 vmov.8 d18[2], r0 64: ee400b90 vmov.8 d16[0], r0 70: ee420bb0 vmov.8 d18[1], r0 /* Source code */ #include <arm_neon.h> static uint8x8_t vec[5] static uint8x16_t qvec[5]; void set(uint8_t value) { vec[1] = vset_lane_u8(value, vec[0], 3); vec[2] = vset_lane_u8(value, vec[0], 2); vec[3] = vset_lane_u8(value, vec[0], 1); vec[4] = vset_lane_u8(value, vec[0], 0); qvec[1] = vsetq_lane_u8(value, qvec[0], 3); qvec[2] = vsetq_lane_u8(value, qvec[0], 2); qvec[3] = vsetq_lane_u8(value, qvec[0], 1); qvec[4] = vsetq_lane_u8(value, qvec[0], 0); } Thx Lee

12 years, 11 months

[ACTIVITY] April 27-28

by Ira Rosen

Hi, gcc-linaro/4.6 - if-conversion improvement (needed to vectorize Telecom/viterbi) - merged - auto-detection of vector size - proposed for merging GCC FSF - fixed PR 48765 on trunk - completed testig of vzip fix (PR 48252) on gcc 4.5 and gcc 4.6 Ira

12 years, 11 months

[ACTIVITY] weekly status

by Ken Werner

Hi, libunwind: * the initial support for resuming at a certain stack frame went upsream * learned about the various signal frame layouts on ARM * RT frames, non-RT frames for present and pre 2.6.18 kernels * implemented support for RT signal frame detection on ARM * started to implement support for unw_resume if signal frames are involved * attended a class on Friday Note: Monday was a public holiday. Regards Ken

12 years, 12 months

[ACTIVITY] Apr 26 - Apr 29

by Ulrich Weigand

== GDB == * Committed series of patches to fix bug #615978 (Failure to software single-step into signal handler) to mainline and Linaro GDB. * Drafted blueprint linaro-toolchain-o-cross-debug == GCC == * Split bug #771900 (Linaro GCC 4.5 switch optimization breaks profiled bootstrap) off bug #759409 (Profiled bootstrap fails in GCC 4.5). Tracked down root cause of bug #759409 / PR middle-end/43085, and posted fix to gcc-patches. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

12 years, 12 months

Toolchain summit blueprints

by Michael Hope

Hi there. The toolchain session blueprints for the summit are now up on Launchpad: https://blueprints.launchpad.net/linaro-toolchain?searchtext=toolchain-o You can check out the schedule here: http://summit.ubuntu.com/uds-o/track/linaro-toolchain/ although it's really only for show at the moment. Expect things to jump around as the constraints kick in. Please go through these blueprints and subscribe yourself to them. You can check your list of blueprints at: https://blueprints.launchpad.net/people/+me?searchtext=toolchain-o -- Michael

12 years, 12 months

"BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

by Barry Song

Hi All, I found Jie has committed a patch "http://sourceware.org/ml/binutils/2010-05/msg00083.html". I am using the newest binary utils(2.21) and encounted the following ASSERT in arm_elf32.c: + if (out_attr[i].i == 0) + { + BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0); My compiling options are as below, ASM_FLAGS := \ -gdwarf-2 \ -mfpu=vfp \ -mfloat-abi=softfp \ -mthumb-interwork C_FLAGS := \ $(ASM_FLAGS) \ -O3 -Wno-all \ -fno-optimize-sibling-calls \ -mlong-calls \ -ffunction-sections \ CPP_FLAGS := \ -fno-rtti \ -fno-exceptions \ LINK_FLAGS := \ --gc-sections -nostdlib \ -L ../stdlib \ -Wl,--as-needed \ -Wl,-no-enum-size-warning \ --cref \ ARFLAGS := \ rcs Can anyone give me any tip about why the assert is triggered? I have reported a bug here: http://sourceware.org/bugzilla/show_bug.cgi?id=12700 But not sure whether it is a bug. -barry

12 years, 12 months

__aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

by Barry Song

Hi All, I am using 2011.3 4.5 linaro GCC(armv7-a vfpv3d16) to compile kernel and modules. I select to compile all codecs as modules: "config SND_SOC_ALL_CODECS tristate "Build all ASoC CODEC drivers" " as M and I2C/SPI too. Then in the kernel dir, run "make" to get both vmlinux and modules, I found snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko will fail due to "__aeabi_uldivmod undefined". If i comment do_div() in these codec drivers, this issue will disappear. But it is strange there are many codecs which use do_div() too, for example: sound/soc/codecs/max98088.c sound/soc/codecs/max9850.c sound/soc/codecs/wm8350.c sound/soc/codecs/wm8400.c sound/soc/codecs/wm8510.c sound/soc/codecs/wm8580.c sound/soc/codecs/wm8753.c sound/soc/codecs/wm8804.c sound/soc/codecs/wm8900.c sound/soc/codecs/wm8904.c sound/soc/codecs/wm8940.c sound/soc/codecs/wm8955.c sound/soc/codecs/wm8960.c sound/soc/codecs/wm8974.c sound/soc/codecs/wm8978.c sound/soc/codecs/wm8985.c sound/soc/codecs/wm8990.c sound/soc/codecs/wm8991.c sound/soc/codecs/wm8993.c sound/soc/codecs/wm8994.c sound/soc/codecs/wm8995.c sound/soc/codecs/wm9081.c but others can pass the compiling except those 3 modules. Is it due to a wrong optimization by gcc? Other information: 1. old tool-chains we are using can pass the compiling of the 3 modules. 2. If i built all codecs into kernel image, these 3 drivers don't report error while compiling. Thanks Barry

12 years, 12 months

Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

by Barry Song

2011/4/27 Mark Brown <broonie(a)opensource.wolfsonmicro.com> > > On Wed, Apr 27, 2011 at 04:50:12PM +0800, Barry Song wrote: > > > Marking pll_factors() as noinline or putting asm("" : "+r"(source)); before the > > call to do_div() works around the problem. > > If we do have to do something in the callers rather than in do_div() the > annotation seems substantially more taseful than inserting a random asm > into the code. I agree. for this patch which will not be applied, people can just get information about how to workaround the gcc issue while they have the same problem. google can find there are other people who failed to compile wm8974 module too. eg. http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt Andrew Stubbs, Michael Hope in Linaro's toolchain team are working hard on this gcc issue. there have been many update today: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783

12 years, 12 months

-O2 cause optimization issues while va parameters functions

by Barry Song

Hi All, As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the following codes, if we compile it by -O2, it will crash with "segment fault", if we just comment " if(unifi_debug >= level) {", all will be ok. If we don't compile it by -O2, all will be ok too. #include <stdlib.h> #include <stdio.h> #include <stdarg.h> #define DEBUG_BUFFER_SIZE 80 int unifi_debug = 5; void unifi_trace(void* ospriv, int level, const char *fmt, ...) { static char s[DEBUG_BUFFER_SIZE]; va_list args; unsigned int len; if(unifi_debug >= level) { va_start(args, fmt); len = vsnprintf(&(s)[0], (DEBUG_BUFFER_SIZE), fmt, args); va_end(args); if (len >= DEBUG_BUFFER_SIZE) { (s)[DEBUG_BUFFER_SIZE - 2] = '\n'; (s)[DEBUG_BUFFER_SIZE - 1] = 0; } printf("%s", s); } } int main(void) { char *prog = "/usr/sbin/unififw"; unifi_trace(NULL, 1, "start %s\n", prog); return 0; } Thanks Barry

12 years, 12 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain April 2011