linaro-toolchain June 2011

linaro-toolchain@lists.linaro.org

28 participants
50 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.

13 years, 6 months

Generating ancilliary sections with gas (fwd)

by Nicolas Pitre

Hello Michael, We do have more and more instances of the following issues turning up in the kernel requiring toolchain assistance to solve the problem properly. Could you or someone from your team follow this up please? ---------- Forwarded message ---------- Date: Tue, 1 Feb 2011 12:16:48 +0000 From: Dave Martin <dave.martin(a)linaro.org> To: binutils(a)sourceware.org Cc: linaro-toolchain <linaro-toolchain(a)lists.linaro.org> Subject: Generating ancilliary sections with gas Hi all, Every now and again I come across a situation where it would be really useful to be able to query the assembler state during assembly: for example, to query and do something based on the current section name. This makes it possible to write generic macros to do certain things which otherwise require manual maintenance, or complex and fragile external preprocessing. Below, I give a real-world example of the problem, and sketch out a possible solution. What do people think of this approach? Does anyone have any better ideas on how to solve this? Cheers ---Dave EXAMPLE An example is the generation of custom ancilliary sections. Suppose you want to write macros which record fixup information. Currently, there's no way to put each fixup in an appropriately named section automatically within gas. Tellingly, gas has had to grow the ability to do this internally at least for ARM, since the exception handling information in .ARM.ex{idx,tab}* must go in sections with names based on the associated section name. However, this ancillary section generation support is neither flexible nor exposed to the user. By putting fixups in sections whose names are based on the name of the section they refer to, selective link-time discard of the fixups (and hence the code referenced by the fixups) will work; otherwise it doesn't. This would help avoid a situation where we have to keep dead code in the kernel because custom fixups are applied to it: at run-time, the code gets fixed up, then is thrown away. The fixups can't be selectively discarded because they are all in the same section: we seem have to no good way to separate them out into separate sections appropriately. For context, see: http://www.spinics.net/lists/arm-kernel/msg112268.html PROPOSAL To solve the problem of generating custom ancillary sections during assembly, here's a simple proposal: introducing a new kind of macro argument can make aspects of the assembler state available to macros in a flexible way, with only minimal implementation required. Basically, the macro qualifier field could be used to identify arguments which are filled in by the assembler with information about the assembly state, rather than being filled in by the invoker of the macro: e.g.: .macro mymacro name:req, flags, secname:current_section /* ... */ .pushsection "\secname\name", "\flags" /* ... */ .popsection .endm /* ... */ mymacro .ancillary, "a" During expansion, \name and \flags are expanded as normal. But \secname is substituted instead with the current section name, so the macro expansion would look like this: /* ... */ .pushsection ".text.ancillary", "a" /* ... */ .popsection Without the special :current_section argument, it doesn't appear possible to implement a macro such as mymacro in a generic way. This surely isn't the only way to achieve the goal, and it's probably not the best way, but it does have some desirable features. Principally, while a new pseudo-op(s) could have been defined to append text to the current section name, etc., allowing the current section name to be appear as a macro parameter avoids prejudicing the way the text is used. So there should never be a need to introduce additional pseudo-ops to do things with the current section name: with this patch, the user can always implement their own macro to do the desired thing. This gets the desired behaviour and maximum flexibility, while keeping the implementation in gas very simple. Also, using the macro expansion system in this way allows the caller a free choice of macro parameter names, and so pretty much guarantees that existing code won't get broken by the change. Because my hack is currently simplistic, it has shortcomings: in particular, it's not desirable to parse an argument from the invocation line at all to fill a :current_section argument. Currently, an argument is read in if present, but its value is ignored and the current section name pasted in at macro expansion time instead. However, that should be straightforward to fix with a bit more code. Of course, there's no reason only to expose the current section name in this way. Any aspect of the the assembler state (current subsection, current section flags, current instruction set, current macro mode, etc.) could be made available in a similar way. USAGE EXAMPLE AND PATCH Note that the specific implementation described here is intended to be illustrative, rather than complete or final. binutils$ cat <<EOF >tst.s .macro push_ancillary_section name:req, flags, csec:current_section .pushsection "\name\csec", "\flags" .endm .macro register_fixup _register_fixup 100\@ .endm .macro _register_fixup label:req \label : push_ancillary_section .fixup, "a" .long \label\(b) .popsection .endm .long 1 register_fixup .long 2 .data .long 3 register_fixup .long 4 .long 5 register_fixup .long 6 EOF binutils$ gas/as-new -ahlms -o tst.o tst.s ARM GAS tst.s page 1 1 .macro push_ancillary_section name:req, flags, csec:current_section 2 .pushsection "\name\csec", "\flags" 3 .endm 4 5 .macro register_fixup 6 _register_fixup 100\@ 7 .endm 8 9 .macro _register_fixup label:req 10 \label : 11 push_ancillary_section .fixup, "a" 12 .long \label\(b) 13 .popsection 14 .endm 15 16 0000 01000000 .long 1 17 register_fixup 17 > _register_fixup 1000 17 >> 1000: 17 >> push_ancillary_section .fixup,"a" 17 >>> .pushsection ".fixup.text","a" 17 0000 04000000 >> .long 1000b 17 >> .popsection 18 0004 02000000 .long 2 19 20 .data 21 0000 03000000 .long 3 22 register_fixup 22 > _register_fixup 1003 22 >> 1003: 22 >> push_ancillary_section .fixup,"a" 22 >>> .pushsection ".fixup.data","a" 22 0000 04000000 >> .long 1003b 22 >> .popsection 23 0004 04000000 .long 4 24 0008 05000000 .long 5 25 register_fixup 25 > _register_fixup 1006 25 >> 1006: 25 >> push_ancillary_section .fixup,"a" 25 >>> .pushsection ".fixup.data","a" 25 0004 0C000000 >> .long 1006b 25 >> .popsection 26 000c 06000000 .long 6 ARM GAS tst.s page 2 NO DEFINED SYMBOLS NO UNDEFINED SYMBOLS binutils$ arm-linux-gnueabi-objdump -rs tst.o tst.o: file format elf32-littlearm RELOCATION RECORDS FOR [.fixup.text]: OFFSET TYPE VALUE 00000000 R_ARM_ABS32 .text RELOCATION RECORDS FOR [.fixup.data]: OFFSET TYPE VALUE 00000000 R_ARM_ABS32 .data 00000004 R_ARM_ABS32 .data Contents of section .text: 0000 01000000 02000000 ........ Contents of section .data: 0000 03000000 04000000 05000000 06000000 ................ Contents of section .fixup.text: 0000 04000000 .... Contents of section .fixup.data: 0000 04000000 0c000000 ........ Contents of section .ARM.attributes: 0000 41150000 00616561 62690001 0b000000 A....aeabi...... 0010 08010901 2c01 ....,. diff --git a/gas/macro.c b/gas/macro.c index e392883..95c4de1 100644 --- a/gas/macro.c +++ b/gas/macro.c @@ -516,6 +516,8 @@ do_formals (macro_entry *macro, int idx, sb *in) formal->type = FORMAL_REQUIRED; else if (strcmp (qual.ptr, "vararg") == 0) formal->type = FORMAL_VARARG; + else if (strcmp (qual.ptr, "current_section") == 0) + formal->type = FORMAL_CURRENT_SECTION; else as_bad_where (macro->file, macro->line, @@ -540,6 +542,15 @@ do_formals (macro_entry *macro, int idx, sb *in) name, macro->name); } + else if (formal->type == FORMAL_CURRENT_SECTION) + { + sb_reset (&formal->def); + as_warn_where (macro->file, + macro->line, + _("Pointless default value for current_section parameter `%s' in macro `%s'"), + name, + macro->name); + } } /* Add to macro's hash table. */ @@ -734,7 +745,11 @@ sub_actual (int start, sb *in, sb *t, struct hash_control *formal_hash, ptr = (formal_entry *) hash_find (formal_hash, sb_terminate (t)); if (ptr) { - if (ptr->actual.len) + if (ptr->type == FORMAL_CURRENT_SECTION) + { + sb_add_string (out, segment_name (now_seg)); + } + else if (ptr->actual.len) { sb_add_sb (out, &ptr->actual); } diff --git a/gas/macro.h b/gas/macro.h index edc1b6b..ea6cabb 100644 --- a/gas/macro.h +++ b/gas/macro.h @@ -38,7 +38,8 @@ enum formal_type { FORMAL_OPTIONAL, FORMAL_REQUIRED, - FORMAL_VARARG + FORMAL_VARARG, + FORMAL_CURRENT_SECTION, }; /* Describe the formal arguments to a macro. */ _______________________________________________ linaro-toolchain mailing list linaro-toolchain(a)lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain

13 years, 9 months

No usb on omap3: 4.6 toolchain issue?

by Paolo Pisati

It all started with this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/791552 basically, switching toolchain from 4.5 to 4.6, somehow broke usb on omap3. This morning i tested with linux-linaro-natty: [flag@newluxor linux-linaro-natty]$ git log --oneline -1 f15fd8f LINARO: Linux-linaro-2.6.38-1002.3 and i can reproduce the problem there too. Here is some more info (dmesg, toolchain, lsusb, etcetc): http://pastebin.ubuntu.com/620786/ -- bye, p.

13 years, 9 months

[ACTIVITY] June 26-30

by Ira Rosen

Hi, - support of multiple uses of original pattern statements (needed for over-promotion work) - committed upstream - support of widen-mult of unsigned types and constants - merged to gcc-linaro-4.6 - vectorizer peeling heuristic improvement - proposed to merge to gcc-linaro-4.6 Ira

13 years, 10 months

Fwd: [Bug gas/12931] ARM: gas fails to set the proper alignment on code sections, causing broken output

by Dave Martin

See the following commit in binutils trunk. If this is causing problems in other places, it could be worth considering for backport into the linaro tools. Cheers ---Dave http://sourceware.org/bugzilla/show_bug.cgi?id=12931 --- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> 2011-06-29 16:29:43 UTC --- CVSROOT: /cvs/src Module name: src Changes by: nickc(a)sourceware.org 2011-06-29 16:29:38 Modified files: gas : ChangeLog gas/config : tc-arm.c Log message: PR gas/12931 * config/tc-arm.c (mapping_state): When changing to ARM or THUMB state set the minimum required alignment of the section. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/ChangeLog.diff?cvsroot=src… http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/config/tc-arm.c.diff?cvsro…

13 years, 10 months

iDCT implementation in GCC NEON intrinsics, for your perusal

by Michael K. Edwards

Here's an implementation of an 8x8 integer DCT done with NEON intrinsics -- essentially a translation of the assembly version in libjpeg-turbo trunk: https://github.com/mkedwards/crosstool-ng/blob/master/patches/libjpeg-turbo… It is in a compilable (on Linaro 2011.05 GCC 4.5, anyway; a recent Linaro 4.6 snapshot ICEs) but otherwise untested state. Still, it's interesting to compare the assembly that it generates against the hand-written version. I thought I'd give linaro-toolchain a heads-up in case y'all could use a test case that generates plenty of pressure on the VFP/NEON register bank. (I intend to use it to see how much performance difference there really is, on the A8 and A9, between NEON code compiled for 16 vs. 32 registers.) Cheers, - Michael

13 years, 10 months

Added an ARMv5E board

by Michael Hope

I've added a pico-SAM9G45 board to my home office setup. It's called libra1 and runs Debian 6.0. The nice thing about this board is it has 256 MB of RAM and should be able to run SPEC 2000. I'll start using it to check that our GCC changes don't cause significant performance regressions on earlier architectures. Dave, you could use it to test the 64 bit primitives if you want. There's more information on the configuration at: http://bazaar.launchpad.net/~michaelh1/+junk/hardware/view/head:/libra/r1/R… -- Michael

13 years, 10 months

GCC cross compilation help: [cannot compute suffix of object files]

by mins.lin＠globalunichip.com

Hello, I tried to build the gcc-linaro cross compiler tool on the x86_64 ubuntu-10.04 machine. The build and host machine is the x86_64 ubuntu-10.04, the target is arm-eabi. But failed and got the following error messages: ----- checking host system type... arm-unknown-eabi checking for arm-eabi-ar... arm-eabi-ar checking for arm-eabi-lipo... arm-eabi-lipo checking for arm-eabi-nm... /home/minslin/ET0001A/build-gcc/./gcc/nm checking for arm-eabi-ranlib... arm-eabi-ranlib checking for arm-eabi-strip... arm-eabi-strip checking whether ln -s works... yes checking for arm-eabi-gcc... /home/minslin/ET0001A/build-gcc/./gcc/xgcc -B/home/minslin/ET0001A/build-gcc/./gcc/ -B/home/minslin/linaro-gcc/arm-eabi/bin/ -B/home/minslin/linaro-gcc/arm-eabi/lib/ -isystem /home/minslin/linaro-gcc/arm-eabi/include -isystem /home/minslin/linaro-gcc/arm-eabi/sys-include checking for suffix of object files... configure: error: in `/home/minslin/ET0001A/build-gcc/arm-eabi/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[1]: *** [configure-target-libgcc] Error 1 make[1]: Leaving directory `/home/minslin/ET0001A/build-gcc' make: *** [all] Error 2 ----- The configure options I used were: ----- ../gcc-linaro-4.5-2011.06-0/configure --target=arm-eabi --enable-languages=c,c++ --enable-shared --prefix=/home/minslin/linaro-gcc --with-gmp=/home/minslin/gmp --with-mpfr=/home/minslin/mpfr --with-mpc=/home/minslin/mpc ----- I downloaded and built the GMP, MPFR and MPC packages. The versions I used are: gmp-5.0.2 mpfr-3.0.1 mpc-0.8.2 Please help me solving this problem. Thanks. Best regards, ------------------------------------------------------------ Min-Shong Lin (林敏雄) Engineering Division Global UniChip Corp. (創意電子) EMAIL : mins.lin(a)globalunichip.com TEL : +886-3-5646600 ext. 6937 --------------------------------- Email Confidentiality Notice ------------------------------------------ If you are not the intended recipient for this CONFIDENTIAL E-mail, please delete it immediately without keeping or distributing any copy and notify the sender. ----------------------------------------------------------------------------------------------------------------------

13 years, 10 months

[ACTIVITY] 20th - 24th June

by Andrew Stubbs

Continued work on widening multiplies. Finally got a point where I have something I'm happy to post upstream! Posted here: http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08720.html Richard Guenther reviewed one of the patches, and found a flaw, so I've been working on addresssing that. Booked hotel for August sprint. ---- Upstream patched requiring review: * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html * Widening Multiplies 1/7 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08721.html * Widening Multiplies 2/7 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08723.html * Widening Multiplies 3/7 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08724.html * Widening Multiplies 4/7 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08725.html * Widening Multiplies 5/7 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08726.html * Widening Multiplies 6/7 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08727.html * Widening Multiplies 7/7 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08728.html

13 years, 10 months

[ACTIVITY] 2011-06-24

by David Gilbert

== Atomics == * Testing the libgcc fallback code with Nicholas's kernel patch - and then fixing my initialisation code to use init_array's (thanks Richard for the hint) * Tidying stuff up after a review of my patch by Richard - the sync.md is now smaller than the original before I started. * Discussing sync semantics with Michael Edwards - he's spotted that the gcc ARM sync routines need to move their final memory barrier for the compare-exchange case where the compare fails. * Looking at valgrind; it looks like it should be OK with the commpage changes; but it doesn't currently support ldrexd and strexd; there is a patch for it to do ARM mode but not thumb yet. Dave

13 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain June 2011