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.
On Tue, Apr 19, 2011 at 5:39 AM, AJ ONeal coolaj86@gmail.com wrote:
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.
Hi AJ. __aeabi_unwind_cpp_pr0 is part of the standard ARM exception handling code and helps in unwinding the stack frame when an exception occurs. This suggests that the binary cmem.a470MV can throw exceptions and therefore needs exception handling.
I don't think this is a toolchain bug as this function is included in libgcc_eh.a and is normally pulled in automatically. Could you add '-v' to your linker flags and send through the result?
-- Michael
What is an "exception" in C?
There is no CPP (.cpp or .cxx) code in any of these libraries.
Interesting thing though: cmem has a userspace and kernelspace component. TI does really nasty stuff, like pull in .h files from the kernel and whatnot. I just tried again against the 2.6.38 kernel (was 2.6.36 this morning) and there is no error.
http://lxr.free-electrons.com/ident?i=__aeabi_unwind_cpp_pr0
Perhaps it's just something in my .config that turns that on or off in the kernel.
AJ ONeal
On Mon, Apr 18, 2011 at 3:06 PM, Michael Hope michael.hope@linaro.orgwrote:
On Tue, Apr 19, 2011 at 5:39 AM, AJ ONeal coolaj86@gmail.com wrote:
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.
Hi AJ. __aeabi_unwind_cpp_pr0 is part of the standard ARM exception handling code and helps in unwinding the stack frame when an exception occurs. This suggests that the binary cmem.a470MV can throw exceptions and therefore needs exception handling.
I don't think this is a toolchain bug as this function is included in libgcc_eh.a and is normally pulled in automatically. Could you add '-v' to your linker flags and send through the result?
-- Michael
Hi AJ. Exception support can still be turned on in C code when it's supposed to interoperate with C++ code. An example is the 64 bit division routine in libgcc - it could potentially throw a division by zero exception when called from C++ code even though the function is written in C.
-- Michael
On Tue, Apr 19, 2011 at 10:38 AM, AJ ONeal coolaj86@gmail.com wrote:
What is an "exception" in C? There is no CPP (.cpp or .cxx) code in any of these libraries.
Interesting thing though: cmem has a userspace and kernelspace component. TI does really nasty stuff, like pull in .h files from the kernel and whatnot. I just tried again against the 2.6.38 kernel (was 2.6.36 this morning) and there is no error. http://lxr.free-electrons.com/ident?i=__aeabi_unwind_cpp_pr0 Perhaps it's just something in my .config that turns that on or off in the kernel. AJ ONeal
On Mon, Apr 18, 2011 at 3:06 PM, Michael Hope michael.hope@linaro.org wrote:
On Tue, Apr 19, 2011 at 5:39 AM, AJ ONeal coolaj86@gmail.com wrote:
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.
Hi AJ. __aeabi_unwind_cpp_pr0 is part of the standard ARM exception handling code and helps in unwinding the stack frame when an exception occurs. This suggests that the binary cmem.a470MV can throw exceptions and therefore needs exception handling.
I don't think this is a toolchain bug as this function is included in libgcc_eh.a and is normally pulled in automatically. Could you add '-v' to your linker flags and send through the result?
-- Michael
On Tue, Apr 19, 2011 at 10:58:28AM +1200, Michael Hope wrote:
Hi AJ. Exception support can still be turned on in C code when it's supposed to interoperate with C++ code. An example is the 64 bit division routine in libgcc - it could potentially throw a division by zero exception when called from C++ code even though the function is written in C.
Just highlighting a feature I found on my travels through the GCC docs:
GCC also supports some language extensions such as __attribute__ (( __cleanup __ )) which allows C programs to do specific work (such as freeing heap buffers) during stack unwinding.
This can be used to write C libraries which exceptions can be through _through_ safely with interoperating with C++.
Cheers, ---Dave
I forgot to post back that I did eventually find the solution to this problem. I had it come back and bite me in the butt a second time and it took me a lot longer to figure it out because I kept finding this thread and not the thread where I had made mention of the solution.
Dear Future AJ,
This is how you solved the problem:
http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/104381.as...
A little tweak to linkcmd.xdt got me most of the way there. ~/ti/dvsdk/dvsdk_3_01_00_10/xdctools_3_16_01_27/packages/gnu/targets/arm/linkcmd.xdt
INPUT( %for (var i = 0; i < $args.length; i++) { `$args[i]` %}
/usr/lib/gcc/arm-linux-gnueabi/4.5.2/libgcc_eh.a
/usr/lib/arm-linux-gnueabi/libc.a
/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.5/libgcc.a )
Also:
__aeabi_unwind_cpp_pr0 is part of the standard ARM exception
handling code and helps in unwinding the stack frame when an exception occurs.
__aeabi_unwind_cpp_pr0 is defined in libgcc_eh.a
Additionally, I believe the problem can be solved by coping
/* Dummy functions to avoid linker complaints */ void __aeabi_unwind_cpp_pr0(void) { };
to cmemk.c
I'm testing both methods again. If anything is different this time around I'll be posting back with more updates.
AJ ONeal
On Mon, Apr 18, 2011 at 11:39 AM, AJ ONeal coolaj86@gmail.com wrote:
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.
linaro-toolchain@lists.linaro.org
-
AJ ONeal -
Dave Martin -
Michael Hope