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.htmlhttp://comments.gmane.org/gmane.comp.boot-loaders.u-boot/78649http://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.
* Looking into SMS patches sent to mainline which expands SMS
functionally to avoid using doloop. The patches resolve the recent
bootstrap failure on mainline.
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01807.html
* Continue looking into 462.libquantum.
Valgrind wants a less stripped ld-2.12.1.so or it won't work. The build
process (that Michael Hope put together) just downloads the
libc6_2.12.1-0ubuntu6_armel.deb, and the ld-2.12.1.so in there is fully
stripped. I thought I'd be able to just get the
libc6-dbg_2.12.1-0ubuntu6_armel.deb instead, thinking that was just the
pre-stripped version of these libs -- but apparently it's not, because
trying to use those libs instead of the stripped ones results in undefined
symbols. For example, ld-2.12.1.so defines _rtld_global -- but
libc-2.12.1.so is looking for _rtld_global@@GLIBC_PRIVATE, so
_rtld_global@@GLIBC_PRIVATE
ends up undefined. (Ditto for __tls_get_addr, __libc_enable_secure,
_dl_argv, etc.)
I'm not sure who actually builds these packages (they're retrieved from:
http://ports.ubuntu.com/pool/main/e/eglibc/), but if anyone has any
suggestions on how to get past this, I'd be most appreciative. (I've got
angry developers trying to track down memory issues, who about to come after
me with torches and pitchforks :P )
Thanks,
Diane
== GDB ==
* Committed second mainline patch to fix re-built executable
remote test problems (#804392).
* Prepared for rebasing Linaro GDB on top of GDB 7.3 release.
== Misc ==
* Prepared for Linaro Connect.
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
Hi,
* Monday was full of IBM internal meetings
* Android
* got a self built LEB and generic version 2.3.4 of linaro android
running on my pandaboard (build with the gcc 4.6 07 release plus the
patch that Richard made)
* requires libicui18n.so (external/icu4c/i18n) to be built with -O2
* ran into a few issues (816491, 807230)
* libunwind:
* simplified the local unwinding (there is no need to touch the ARM
exidx table segment when looking it up)
* fixed a bug (corner case: the info of the IP to be unwound is
described by the last unw entry)
* made some progress on the remote unwinding via ptrace
* remotely searching the unw withing entry exidx table segment
* next step is to remotely extract the unw isns
Regards
Ken
RAG:
Red:
Amber: OMAP3 patch upstreaming is slower progress than hoped
Green: various outstanding patches accepted upstream in time for 0.15
Current Milestones:
|| || Planned || Estimate || Actual ||
||qemu-linaro 2011-08 || 2011-08-18 || 2011-08-18 || ||
Historical Milestones:
||qemu-linaro 2011-04 || 2011-04-21 || 2011-04-21 || 2011-04-21 ||
||qemu-linaro 2011-05 || 2011-05-19 || 2011-05-19 || n/a ||
||close out 1105 blueprints || 2011-05-28 || 2011-05-28 || 2011-05-19 ||
||complete 1111 planning || 2011-05-28 || 2011-05-28 || 2011-05-27 ||
||qemu-linaro-2011-06 || 2011-06-16 || 2011-06-16 || 2011-06-16 ||
||qemu-linaro-2011-07 || 2011-07-21 || 2011-07-21 || 2011-07-21 ||
== upstream-omap3-patches ==
* omap-gpmc patches now all cleaned up; I think I need to look at
qdevifying this device before submitting patches, though
* sent patch for bug which makes n810 model crash when key is pressed
* sent a pull request collecting together the patches submitted so far
== other ==
* qemu 0.15: put together pull request for ARM patches I think should
go into this release; wrote ARM-related bits of the release notes
* helped GSoC student track down a bug causing android not to boot
* LP:816791: tracking down issues with running mono under qemu
(combination of a couple of known qemu bugs and a mono bug)
* admin/prep for upcoming travel (cambourne, vancouver, orlando)
* reviewing pl041 patches which add audio support to versatilepb
and vexpress models
* mailing list discussion of possible new qemu object model
* lots of meetings this week (toolchain, standup, doughnuts, team
comms x2)
Current qemu patch status is tracked here:
https://wiki.linaro.org/PeterMaydell/QemuPatchStatus
Absences:
1-5 August: Linaro sprint 1111
15-19 August: KVM Forum and LinuxCon NA, Vancouver
the current gcc-4.6/eglibc is now built multilib'd for -mfloat-abi=softfp|hard,
including the GCC runtime libraries. I hope that the gcc cross builds will pick
this up soonish, not needing to build the cross compiler twice for softfp and
hard float-abi.
Matthias
== 64 bit atomics ==
* Sent updated set of 64bit atomic patches to gcc list with fixes
from previous review
* Started hunting for other users of 64bit atomics than membase
jemalloc, sdl and boost lock free look like possibilities; but I've
not looked at them hard yet
== QEmu ==
* Released fix for last SD card block access error
- Vincent Palatin released a bunch of SD card fixes a few hours
later - that included a fix to the same bug; however it does look like
he has a bunch of other stuff we should keep sync'd with.
* Changing caching mode to writeback on the block layer fixes bug
732223 (hangs on heavy IO) - goes from 130KB/s to 8MB/s on vexpress
- Asked mailing list whether that's reasonable to make as default for SD
* Looking at path from CPU->MMC/SD card - the DMA on OMAP is pretty
inefficiently emulated, but the soc_dma code has an unused special
case for dma'ing to hardware, looks promising but need to figure
out how to use it and if it works.
* Comparing Vincent's SD card patch with earlier meego patches;
partial overlap.
== Other ==
* Pinged libc-ports for comments on my optimised memchr patch
* Image testing
Next week; I intend to be in Camborne on the afternoon of Monday,
Wednesday and Friday.
Dave
Hi,
I am checking the coverage of the NEON instructions mostly by writing
tests in C to check which instructions are generated (after
auto-vectorization) and which are not.
I put here https://wiki.linaro.org/IraRosen/Sandbox/InstructionCoverage
the list of things that I've checked till now.
Ira
Spun release tarballs for Linaro GCC 4.5 and 4.6. Sent them to Michael
Hope and Matthias Klose.
Testing for my widening multiplies patches revealed a bug when the
accumulate value had a different type. The problem is easily fixed, so
I've created a patch, submitted it, and now it's approved upstream.
Same again, this time with a bug involving constant integers. Again,
easily fixed, submitted, and approved.
Nobody had reviewed the first patch in my series - Richard Guenther had
reviewed all the others, but wasn't happy to review the expand pass. So,
I asked newly crowned RTL Maintainer Richard Sandiford to review it, but
apparently it's the wrong bit of the back-end, so I asked Bernd instead.
Bernd kindly reviewed and approved it, so now the whole series is ready
to commit if only my test comes back clean.
Continued trying to figure out why my thumb2 constants patch is broken.
So far, no further progress. It might be that Michael's build system is
confused, but it's looking likely to be a real bug.
----
Upstream patched requiring review:
* NEON scheduling patch
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
