|
From: Brandon R. <br...@co...> - 2009-10-08 20:13:30
|
I get an error when trying to compile to montavista. I'm using this command line argument: ./configure --host=ppc-linux --build=x86_64-linux CXX=ppc_85xx-g++ AR=ppc_85xx-ar CC=ppc_85xx-gcc --disable-tls And the last error is this: ppc_85xx-gcc -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -o vgpreload_memcheck-ppc32-linux.so -nodefaultlibs -shared -Wl,-z,interpose,-z,initfirst -m32 -Wl,--whole-archive ../coregrind/libreplacemalloc_toolpreload-ppc32-linux.a -Wl,--no-whole-archive vgpreload_memcheck_ppc32_linux_so-mc_replace_strmem.o ppc_85xx-gcc -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -o memcheck-ppc32-linux -static -Wl,-defsym,valt_load_address=0x38000000 -nodefaultlibs -nostartfiles -u _start -m32 -Wl,-T,../valt_load_address_ppc32_linux.lds memcheck_ppc32_linux-mc_leakcheck.o memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a ../VEX/libvex-ppc32-linux.a -lgcc ../coregrind/libcoregrind-ppc32-linux.a(libcoregrind_ppc32_linux_a-aspacemgr-linux.o): In function `vgPlain_am_do_sync_check': /home/rootfs/brioja/valgrind/valgrind-3.5.0/coregrind/m_aspacemgr/aspacemgr-linux.c:1059: undefined reference to `parse_procselfmaps' ../coregrind/libcoregrind-ppc32-linux.a(libcoregrind_ppc32_linux_a-aspacemgr-linux.o): In function `vgPlain_am_startup': /home/rootfs/brioja/valgrind/valgrind-3.5.0/coregrind/m_aspacemgr/aspacemgr-linux.c:1683: undefined reference to `parse_procselfmaps' /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(divdf3.o): In function `__divdf3': /home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/divdf3.c:44: undefined reference to `abort' /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(muldf3.o): In function `__muldf3': /home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/muldf3.c:44: undefined reference to `abort' collect2: ld returned 1 exit status make[4]: *** [memcheck-ppc32-linux] Error 1 make[4]: Leaving directory `/home/rootfs/brioja/valgrind/valgrind-3.5.0/memcheck' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/rootfs/brioja/valgrind/valgrind-3.5.0/memcheck' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/rootfs/brioja/valgrind/valgrind-3.5.0/memcheck' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/rootfs/brioja/valgrind/valgrind-3.5.0' make: *** [all] Error 2 Brandon Rioja Software Engineer Video Systems Division Compunetix, Inc. br...@co... (412) 858-6108 (Direct) |
|
From: Bart V. A. <bar...@gm...> - 2009-10-09 10:06:15
|
On Thu, Oct 8, 2009 at 10:00 PM, Brandon Rioja <br...@co...> wrote: > I get an error when trying to compile to montavista. > > I'm using this command line argument: > > ./configure --host=ppc-linux --build=x86_64-linux CXX=ppc_85xx-g++ AR=ppc_85xx-ar CC=ppc_85xx-gcc --disable-tls > [ ... ] Cross-compilation of Valgrind works fine for other Valgrind users, so there is probably something wrong with the above command line. Bart. |
|
From: Mogens L. L. <ML...@ba...> - 2009-10-09 11:10:46
|
I build valgrind for PPC using cross compiler like this:
#*****************
export location=$(pwd)
export
TARGET_TOOL_BASE=/opt/wrsysroot/x86-linux2/powerpc-wrs-linux-gnu-ppc_603e-glibc_small-
export CC=${TARGET_TOOL_BASE}gcc
export CXX=${TARGET_TOOL_BASE}g++
export LD=${TARGET_TOOL_BASE}ld
svn co svn://svn.valgrind.org/valgrind/trunk valgrind
cd valgrind
./autogen.sh
./configure --prefix=${location}/install_svn_debug --enable-shared
--host=ppc-linux --target=ppc-linux --enable-debug --disable-tls || exit 1
make || exit 1
make install || exit 1
#***************
This are probably other/betters ways, but this works for me :-)
/Mogens
Bart Van Assche <bar...@gm...>
09-10-2009 12:07
To
Brandon Rioja <br...@co...>
cc
"val...@li..."
<val...@li...>
Subject
Re: [Valgrind-users] Montavista cross compilation
On Thu, Oct 8, 2009 at 10:00 PM, Brandon Rioja <br...@co...>
wrote:
> I get an error when trying to compile to montavista.
>
> I'm using this command line argument:
>
> ./configure --host=ppc-linux --build=x86_64-linux CXX=ppc_85xx-g++
AR=ppc_85xx-ar CC=ppc_85xx-gcc --disable-tls
> [ ... ]
Cross-compilation of Valgrind works fine for other Valgrind users, so
there is probably something wrong with the above command line.
Bart.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Brandon R. <br...@co...> - 2009-10-09 14:43:37
|
I'm getting some problems, still.
This is the error:
/opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -o memcheck-ppc32-linux -static -Wl,-defsym,valt_load_address=0x38000000 -nodefaultlibs -nostartfiles -u _start -m32 -Wl,-T,../valt_load_address_ppc32_linux.lds memcheck_ppc32_linux-mc_leakcheck.o memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a ../VEX/libvex-ppc32-linux.a -lgcc
/opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(divdf3.o): In function `__divdf3':
/home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/divdf3.c:44: undefined reference to `abort'
/opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(muldf3.o): In function `__muldf3':
/home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/muldf3.c:44: undefined reference to `abort'
collect2: ld returned 1 exit status
make[4]: *** [memcheck-ppc32-linux] Error 1
make[4]: Leaving directory `/home/brioja/valgrind/memcheck'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/brioja/valgrind/memcheck'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/brioja/valgrind/memcheck'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/brioja/valgrind'
make: *** [all] Error 2
This is the build script:
#export location=$(pwd)
export TARGET_TOOL_BASE=/opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-
export CC=${TARGET_TOOL_BASE}gcc
export CXX=${TARGET_TOOL_BASE}g++
export LD=${TARGET_TOOL_BASE}ld
#svn co svn://svn.valgrind.org/valgrind/trunk valgrind
cd valgrind
./autogen.sh
./configure --prefix=/home/rootfs/brioja/local/ --host=ppc-linux --target=ppc-linux --enable-debug --disable-tls || exit 1
make || exit 1
make install || exit 1
From: Mogens Lindholdt Lauridsen [mailto:ML...@ba...]
Sent: Friday, October 09, 2009 6:55 AM
To: Bart Van Assche
Cc: Brandon Rioja; val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
I build valgrind for PPC using cross compiler like this:
#*****************
export location=$(pwd)
export TARGET_TOOL_BASE=/opt/wrsysroot/x86-linux2/powerpc-wrs-linux-gnu-ppc_603e-glibc_small-
export CC=${TARGET_TOOL_BASE}gcc
export CXX=${TARGET_TOOL_BASE}g++
export LD=${TARGET_TOOL_BASE}ld
svn co svn://svn.valgrind.org/valgrind/trunk valgrind
cd valgrind
./autogen.sh
./configure --prefix=${location}/install_svn_debug --enable-shared --host=ppc-linux --target=ppc-linux --enable-debug --disable-tls || exit 1
make || exit 1
make install || exit 1
#***************
This are probably other/betters ways, but this works for me :-)
/Mogens
Bart Van Assche <bar...@gm...>
09-10-2009 12:07
To
Brandon Rioja <br...@co...>
cc
"val...@li..." <val...@li...>
Subject
Re: [Valgrind-users] Montavista cross compilation
On Thu, Oct 8, 2009 at 10:00 PM, Brandon Rioja <br...@co...> wrote:
> I get an error when trying to compile to montavista.
>
> I'm using this command line argument:
>
> ./configure --host=ppc-linux --build=x86_64-linux CXX=ppc_85xx-g++ AR=ppc_85xx-ar CC=ppc_85xx-gcc --disable-tls
> [ ... ]
Cross-compilation of Valgrind works fine for other Valgrind users, so
there is probably something wrong with the above command line.
Bart.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Val...@li...
<http://p.sf.net/sfu/devconference>https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Tom H. <to...@co...> - 2009-10-09 14:57:48
|
On 09/10/09 15:43, Brandon Rioja wrote: > I’m getting some problems, still. > > This is the error: > > /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc > -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement > -fno-stack-protector -o memcheck-ppc32-linux -static > -Wl,-defsym,valt_load_address=0x38000000 -nodefaultlibs -nostartfiles -u > _start -m32 -Wl,-T,../valt_load_address_ppc32_linux.lds > memcheck_ppc32_linux-mc_leakcheck.o > memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o > memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o > memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a > ../VEX/libvex-ppc32-linux.a -lgcc > > /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(divdf3.o): > In function `__divdf3': > > /home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/divdf3.c:44: > undefined reference to `abort' It looks like your libgcc has references to the abort() function in the C library but we (deliberately) don't link the with the C library. libgcc is supposed to be low level support routines for gcc generated code to call and shouldn't really be calling C library routines like that as it stops you being able to compile code that doesn't link with the C library. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Brandon R. <br...@co...> - 2009-10-09 15:04:27
|
Ahh, makes sense. I added a random abort() function to one of the files, everything compiles successfully now. Thank you. :-) -----Original Message----- From: Tom Hughes [mailto:to...@co...] Sent: Friday, October 09, 2009 10:57 AM To: Brandon Rioja Cc: Mogens Lindholdt Lauridsen; Bart Van Assche; val...@li... Subject: Re: [Valgrind-users] Montavista cross compilation On 09/10/09 15:43, Brandon Rioja wrote: > I'm getting some problems, still. > > This is the error: > > /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc > -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement > -fno-stack-protector -o memcheck-ppc32-linux -static > -Wl,-defsym,valt_load_address=0x38000000 -nodefaultlibs -nostartfiles -u > _start -m32 -Wl,-T,../valt_load_address_ppc32_linux.lds > memcheck_ppc32_linux-mc_leakcheck.o > memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o > memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o > memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a > ../VEX/libvex-ppc32-linux.a -lgcc > > /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(divdf3.o): > In function `__divdf3': > > /home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/divdf3.c:44: > undefined reference to `abort' It looks like your libgcc has references to the abort() function in the C library but we (deliberately) don't link the with the C library. libgcc is supposed to be low level support routines for gcc generated code to call and shouldn't really be calling C library routines like that as it stops you being able to compile code that doesn't link with the C library. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Brandon R. <br...@co...> - 2009-10-09 15:28:59
|
After I got valgrind to compile, I am having difficulty running. # ./valgrind valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux': No such file or directory -----Original Message----- From: Tom Hughes [mailto:to...@co...] Sent: Friday, October 09, 2009 10:57 AM To: Brandon Rioja Cc: Mogens Lindholdt Lauridsen; Bart Van Assche; val...@li... Subject: Re: [Valgrind-users] Montavista cross compilation On 09/10/09 15:43, Brandon Rioja wrote: > I'm getting some problems, still. > > This is the error: > > /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc > -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement > -fno-stack-protector -o memcheck-ppc32-linux -static > -Wl,-defsym,valt_load_address=0x38000000 -nodefaultlibs -nostartfiles -u > _start -m32 -Wl,-T,../valt_load_address_ppc32_linux.lds > memcheck_ppc32_linux-mc_leakcheck.o > memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o > memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o > memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a > ../VEX/libvex-ppc32-linux.a -lgcc > > /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(divdf3.o): > In function `__divdf3': > > /home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/divdf3.c:44: > undefined reference to `abort' It looks like your libgcc has references to the abort() function in the C library but we (deliberately) don't link the with the C library. libgcc is supposed to be low level support routines for gcc generated code to call and shouldn't really be calling C library routines like that as it stops you being able to compile code that doesn't link with the C library. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Mogens L. L. <ML...@ba...> - 2009-10-09 20:20:29
|
Well, I am sure there is a more elegant way... but this is how I handle
it....
When you build your code, the path for the tools will be set inside
valgrind. So if you build valgrind in:
"/home/foo/valgrind"
You must also make sure it is located in the same path on your target.
I guess you can use "strace valgrind .." to actually see where it expects
to find the memcheck file.
You can probably fix this by setting the --bindir/--sbindir/--libexecdir
on configure when you build valgrind. (I can live with using the same path
when building and running target, so I didn't bother to figure these
setting out. Sorry...)
/Mogens
Brandon Rioja <br...@co...>
09-10-2009 17:31
To
Tom Hughes <to...@co...>
cc
"val...@li..."
<val...@li...>, Mogens Lindholdt Lauridsen
<ML...@ba...>
Subject
Re: [Valgrind-users] Montavista cross compilation
After I got valgrind to compile, I am having difficulty running.
# ./valgrind
valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux': No
such file or directory
-----Original Message-----
From: Tom Hughes [mailto:to...@co...]
Sent: Friday, October 09, 2009 10:57 AM
To: Brandon Rioja
Cc: Mogens Lindholdt Lauridsen; Bart Van Assche;
val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
On 09/10/09 15:43, Brandon Rioja wrote:
> I'm getting some problems, still.
>
> This is the error:
>
> /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc
> -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement
> -fno-stack-protector -o memcheck-ppc32-linux -static
> -Wl,-defsym,valt_load_address=0x38000000 -nodefaultlibs -nostartfiles -u
> _start -m32 -Wl,-T,../valt_load_address_ppc32_linux.lds
> memcheck_ppc32_linux-mc_leakcheck.o
> memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o
> memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o
> memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a
> ../VEX/libvex-ppc32-linux.a -lgcc
>
>
/opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(divdf3.o):
> In function `__divdf3':
>
>
/home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/divdf3.c:44:
> undefined reference to `abort'
It looks like your libgcc has references to the abort() function in the
C library but we (deliberately) don't link the with the C library.
libgcc is supposed to be low level support routines for gcc generated
code to call and shouldn't really be calling C library routines like
that as it stops you being able to compile code that doesn't link with
the C library.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Brandon R. <br...@co...> - 2009-10-09 20:21:47
|
Thanks, again! That worked, too.
From: Mogens Lindholdt Lauridsen [mailto:ML...@ba...]
Sent: Friday, October 09, 2009 4:20 PM
To: Brandon Rioja
Cc: Tom Hughes; val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
Well, I am sure there is a more elegant way... but this is how I handle it....
When you build your code, the path for the tools will be set inside valgrind. So if you build valgrind in:
"/home/foo/valgrind"
You must also make sure it is located in the same path on your target.
I guess you can use "strace valgrind .." to actually see where it expects to find the memcheck file.
You can probably fix this by setting the --bindir/--sbindir/--libexecdir on configure when you build valgrind. (I can live with using the same path when building and running target, so I didn't bother to figure these setting out. Sorry...)
/Mogens
Brandon Rioja <br...@co...>
09-10-2009 17:31
To
Tom Hughes <to...@co...>
cc
"val...@li..." <val...@li...>, Mogens Lindholdt Lauridsen <ML...@ba...>
Subject
Re: [Valgrind-users] Montavista cross compilation
After I got valgrind to compile, I am having difficulty running.
# ./valgrind
valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux': No such file or directory
-----Original Message-----
From: Tom Hughes [mailto:to...@co...]
Sent: Friday, October 09, 2009 10:57 AM
To: Brandon Rioja
Cc: Mogens Lindholdt Lauridsen; Bart Van Assche; val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
On 09/10/09 15:43, Brandon Rioja wrote:
> I'm getting some problems, still.
>
> This is the error:
>
> /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc
> -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement
> -fno-stack-protector -o memcheck-ppc32-linux -static
> -Wl,-defsym,valt_load_address=0x38000000 -nodefaultlibs -nostartfiles -u
> _start -m32 -Wl,-T,../valt_load_address_ppc32_linux.lds
> memcheck_ppc32_linux-mc_leakcheck.o
> memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o
> memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o
> memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a
> ../VEX/libvex-ppc32-linux.a -lgcc
>
> /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(divdf3.o):
> In function `__divdf3':
>
> /home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/divdf3.c:44:
> undefined reference to `abort'
It looks like your libgcc has references to the abort() function in the
C library but we (deliberately) don't link the with the C library.
libgcc is supposed to be low level support routines for gcc generated
code to call and shouldn't really be calling C library routines like
that as it stops you being able to compile code that doesn't link with
the C library.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
<http://www.compton.nu/>http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Val...@li...
<http://p.sf.net/sfu/devconference>https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Brandon R. <br...@co...> - 2009-10-09 20:44:09
|
I am getting an illegal instruction error when running valgrind on a ppc with montavista.
Does anyone have an idea how I can fix this?
# ./valgrind echo hi
==1012== Memcheck, a memory error detector
==1012== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1012== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==1012== Command: echo hi
==1012==
disInstr(ppc): declined to decode an AltiVec insn.
disInstr(ppc): unhandled instruction: 0x13CB0321
primary 4(0x4), secondary 801(0x321)
==1012== valgrind: Unrecognised instruction at address 0x400ec70.
==1012== Your program just tried to execute an instruction that Valgrind
==1012== did not recognise. There are two possible reasons for this.
==1012== 1. Your program has a bug and erroneously jumped to a non-code
==1012== location. If you are running Memcheck and you just saw a
==1012== warning about a bad jump, it's probably your program's fault.
==1012== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1012== i.e. it's Valgrind's fault. If you think this is the case or
==1012== you are not sure, please let us know and we'll try to fix it.
==1012== Either way, Valgrind will now raise a SIGILL signal which will
==1012== probably kill your program.
==1012==
==1012== Process terminating with default action of signal 4 (SIGILL)
==1012== Illegal opcode at address 0x400EC70
==1012== at 0x400EC70: _dl_catch_error (dl-error.c:160)
==1012== by 0x4002CE7: do_preload (rtld.c:804)
==1012== by 0x4005A93: dl_main (rtld.c:1727)
==1012== by 0x401595B: _dl_sysdep_start (dl-sysdep.c:239)
==1012== by 0x4002517: _dl_start_final (rtld.c:323)
==1012== by 0x4002A43: _dl_start (rtld.c:551)
==1012== by 0x40164CF: _start (in /lib/ld-2.5.90.so)
==1012==
==1012== HEAP SUMMARY:
==1012== in use at exit: 0 bytes in 0 blocks
==1012== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1012==
==1012== All heap blocks were freed -- no leaks are possible
==1012==
==1012== For counts of detected and suppressed errors, rerun with: -v
==1012== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 2)
Illegal instruction
From: Mogens Lindholdt Lauridsen [mailto:ML...@ba...]
Sent: Friday, October 09, 2009 4:20 PM
To: Brandon Rioja
Cc: Tom Hughes; val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
Well, I am sure there is a more elegant way... but this is how I handle it....
When you build your code, the path for the tools will be set inside valgrind. So if you build valgrind in:
"/home/foo/valgrind"
You must also make sure it is located in the same path on your target.
I guess you can use "strace valgrind .." to actually see where it expects to find the memcheck file.
You can probably fix this by setting the --bindir/--sbindir/--libexecdir on configure when you build valgrind. (I can live with using the same path when building and running target, so I didn't bother to figure these setting out. Sorry...)
/Mogens
Brandon Rioja <br...@co...>
09-10-2009 17:31
To
Tom Hughes <to...@co...>
cc
"val...@li..." <val...@li...>, Mogens Lindholdt Lauridsen <ML...@ba...>
Subject
Re: [Valgrind-users] Montavista cross compilation
After I got valgrind to compile, I am having difficulty running.
# ./valgrind
valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux': No such file or directory
-----Original Message-----
From: Tom Hughes [mailto:to...@co...]
Sent: Friday, October 09, 2009 10:57 AM
To: Brandon Rioja
Cc: Mogens Lindholdt Lauridsen; Bart Van Assche; val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
On 09/10/09 15:43, Brandon Rioja wrote:
> I'm getting some problems, still.
>
> This is the error:
>
> /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc
> -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement
> -fno-stack-protector -o memcheck-ppc32-linux -static
> -Wl,-defsym,valt_load_address=0x38000000 -nodefaultlibs -nostartfiles -u
> _start -m32 -Wl,-T,../valt_load_address_ppc32_linux.lds
> memcheck_ppc32_linux-mc_leakcheck.o
> memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o
> memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o
> memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a
> ../VEX/libvex-ppc32-linux.a -lgcc
>
> /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(divdf3.o):
> In function `__divdf3':
>
> /home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/divdf3.c:44:
> undefined reference to `abort'
It looks like your libgcc has references to the abort() function in the
C library but we (deliberately) don't link the with the C library.
libgcc is supposed to be low level support routines for gcc generated
code to call and shouldn't really be calling C library routines like
that as it stops you being able to compile code that doesn't link with
the C library.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
<http://www.compton.nu/>http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Val...@li...
<http://p.sf.net/sfu/devconference>https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Mogens L. L. <ML...@ba...> - 2009-10-09 20:58:03
|
>disInstr(ppc): declined to decode an AltiVec insn.
It is an Altivec instruction
I got the same problem, but for my case it was because the PPC I use don't
have altivec support. Valgrind actually helped me here, since I also got
the illigal instruction when running without valgrind, but I didn't know
which instruction caused it.
If your PPC support Altivec, I guess valgrind don't. You might be able to
disable altivec when you build your application, and run your application
with lower performance. (But being able to check your application with
valgrind).
Who and how to add support for Altivec in valgrind, if this is the
problem, I don't know...
/Mogens
Brandon Rioja <br...@co...>
09-10-2009 22:46
To
"val...@li..."
<val...@li...>
cc
Subject
Re: [Valgrind-users] Montavista cross compilation
I am getting an illegal instruction error when running valgrind on a ppc
with montavista.
Does anyone have an idea how I can fix this?
# ./valgrind echo hi
==1012== Memcheck, a memory error detector
==1012== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1012== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright
info
==1012== Command: echo hi
==1012==
disInstr(ppc): declined to decode an AltiVec insn.
disInstr(ppc): unhandled instruction: 0x13CB0321
primary 4(0x4), secondary 801(0x321)
==1012== valgrind: Unrecognised instruction at address 0x400ec70.
==1012== Your program just tried to execute an instruction that Valgrind
==1012== did not recognise. There are two possible reasons for this.
==1012== 1. Your program has a bug and erroneously jumped to a non-code
==1012== location. If you are running Memcheck and you just saw a
==1012== warning about a bad jump, it's probably your program's fault.
==1012== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1012== i.e. it's Valgrind's fault. If you think this is the case or
==1012== you are not sure, please let us know and we'll try to fix it.
==1012== Either way, Valgrind will now raise a SIGILL signal which will
==1012== probably kill your program.
==1012==
==1012== Process terminating with default action of signal 4 (SIGILL)
==1012== Illegal opcode at address 0x400EC70
==1012== at 0x400EC70: _dl_catch_error (dl-error.c:160)
==1012== by 0x4002CE7: do_preload (rtld.c:804)
==1012== by 0x4005A93: dl_main (rtld.c:1727)
==1012== by 0x401595B: _dl_sysdep_start (dl-sysdep.c:239)
==1012== by 0x4002517: _dl_start_final (rtld.c:323)
==1012== by 0x4002A43: _dl_start (rtld.c:551)
==1012== by 0x40164CF: _start (in /lib/ld-2.5.90.so)
==1012==
==1012== HEAP SUMMARY:
==1012== in use at exit: 0 bytes in 0 blocks
==1012== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1012==
==1012== All heap blocks were freed -- no leaks are possible
==1012==
==1012== For counts of detected and suppressed errors, rerun with: -v
==1012== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 2)
Illegal instruction
From: Mogens Lindholdt Lauridsen [mailto:ML...@ba...]
Sent: Friday, October 09, 2009 4:20 PM
To: Brandon Rioja
Cc: Tom Hughes; val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
Well, I am sure there is a more elegant way... but this is how I handle
it....
When you build your code, the path for the tools will be set inside
valgrind. So if you build valgrind in:
"/home/foo/valgrind"
You must also make sure it is located in the same path on your target.
I guess you can use "strace valgrind .." to actually see where it expects
to find the memcheck file.
You can probably fix this by setting the --bindir/--sbindir/--libexecdir
on configure when you build valgrind. (I can live with using the same path
when building and running target, so I didn't bother to figure these
setting out. Sorry...)
/Mogens
Brandon Rioja <br...@co...>
09-10-2009 17:31
To
Tom Hughes <to...@co...>
cc
"val...@li..."
<val...@li...>, Mogens Lindholdt Lauridsen
<ML...@ba...>
Subject
Re: [Valgrind-users] Montavista cross compilation
After I got valgrind to compile, I am having difficulty running.
# ./valgrind
valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux': No
such file or directory
-----Original Message-----
From: Tom Hughes [mailto:to...@co...]
Sent: Friday, October 09, 2009 10:57 AM
To: Brandon Rioja
Cc: Mogens Lindholdt Lauridsen; Bart Van Assche;
val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
On 09/10/09 15:43, Brandon Rioja wrote:
> I'm getting some problems, still.
>
> This is the error:
>
> /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc
> -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement
> -fno-stack-protector -o memcheck-ppc32-linux -static
> -Wl,-defsym,valt_load_address=0x38000000 -nodefaultlibs -nostartfiles -u
> _start -m32 -Wl,-T,../valt_load_address_ppc32_linux.lds
> memcheck_ppc32_linux-mc_leakcheck.o
> memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o
> memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o
> memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a
> ../VEX/libvex-ppc32-linux.a -lgcc
>
>
/opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(divdf3.o):
> In function `__divdf3':
>
>
/home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/divdf3.c:44:
> undefined reference to `abort'
It looks like your libgcc has references to the abort() function in the
C library but we (deliberately) don't link the with the C library.
libgcc is supposed to be low level support routines for gcc generated
code to call and shouldn't really be calling C library routines like
that as it stops you being able to compile code that doesn't link with
the C library.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Brandon R. <br...@co...> - 2009-10-09 21:15:58
|
I tried compiling a simple program with no altivec support.
ppc_85xx-g++ -mno-altivec test.cpp
"""
int main() {
return 0;
}
"""
But I get an error on startup. The altivec instruction seems to still exist.
./valgrind ../../a.out
==1026== Memcheck, a memory error detector
==1026== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1026== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==1026== Command: ../../a.out
==1026==
disInstr(ppc): declined to decode an AltiVec insn.
disInstr(ppc): unhandled instruction: 0x13CB0321
primary 4(0x4), secondary 801(0x321)
I wrote up an issue about this instruction:
https://bugs.kde.org/show_bug.cgi?id=210028
From: Mogens Lindholdt Lauridsen [mailto:ML...@ba...]
Sent: Friday, October 09, 2009 4:58 PM
To: Brandon Rioja
Cc: val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
>disInstr(ppc): declined to decode an AltiVec insn.
It is an Altivec instruction
I got the same problem, but for my case it was because the PPC I use don't have altivec support. Valgrind actually helped me here, since I also got the illigal instruction when running without valgrind, but I didn't know which instruction caused it.
If your PPC support Altivec, I guess valgrind don't. You might be able to disable altivec when you build your application, and run your application with lower performance. (But being able to check your application with valgrind).
Who and how to add support for Altivec in valgrind, if this is the problem, I don't know...
/Mogens
Brandon Rioja <br...@co...>
09-10-2009 22:46
To
"val...@li..." <val...@li...>
cc
Subject
Re: [Valgrind-users] Montavista cross compilation
I am getting an illegal instruction error when running valgrind on a ppc with montavista.
Does anyone have an idea how I can fix this?
# ./valgrind echo hi
==1012== Memcheck, a memory error detector
==1012== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1012== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==1012== Command: echo hi
==1012==
disInstr(ppc): declined to decode an AltiVec insn.
disInstr(ppc): unhandled instruction: 0x13CB0321
primary 4(0x4), secondary 801(0x321)
==1012== valgrind: Unrecognised instruction at address 0x400ec70.
==1012== Your program just tried to execute an instruction that Valgrind
==1012== did not recognise. There are two possible reasons for this.
==1012== 1. Your program has a bug and erroneously jumped to a non-code
==1012== location. If you are running Memcheck and you just saw a
==1012== warning about a bad jump, it's probably your program's fault.
==1012== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1012== i.e. it's Valgrind's fault. If you think this is the case or
==1012== you are not sure, please let us know and we'll try to fix it.
==1012== Either way, Valgrind will now raise a SIGILL signal which will
==1012== probably kill your program.
==1012==
==1012== Process terminating with default action of signal 4 (SIGILL)
==1012== Illegal opcode at address 0x400EC70
==1012== at 0x400EC70: _dl_catch_error (dl-error.c:160)
==1012== by 0x4002CE7: do_preload (rtld.c:804)
==1012== by 0x4005A93: dl_main (rtld.c:1727)
==1012== by 0x401595B: _dl_sysdep_start (dl-sysdep.c:239)
==1012== by 0x4002517: _dl_start_final (rtld.c:323)
==1012== by 0x4002A43: _dl_start (rtld.c:551)
==1012== by 0x40164CF: _start (in /lib/ld-2.5.90.so)
==1012==
==1012== HEAP SUMMARY:
==1012== in use at exit: 0 bytes in 0 blocks
==1012== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1012==
==1012== All heap blocks were freed -- no leaks are possible
==1012==
==1012== For counts of detected and suppressed errors, rerun with: -v
==1012== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 2)
Illegal instruction
From: Mogens Lindholdt Lauridsen [mailto:ML...@ba...]
Sent: Friday, October 09, 2009 4:20 PM
To: Brandon Rioja
Cc: Tom Hughes; val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
Well, I am sure there is a more elegant way... but this is how I handle it....
When you build your code, the path for the tools will be set inside valgrind. So if you build valgrind in:
"/home/foo/valgrind"
You must also make sure it is located in the same path on your target.
I guess you can use "strace valgrind .." to actually see where it expects to find the memcheck file.
You can probably fix this by setting the --bindir/--sbindir/--libexecdir on configure when you build valgrind. (I can live with using the same path when building and running target, so I didn't bother to figure these setting out. Sorry...)
/Mogens
Brandon Rioja <br...@co...>
09-10-2009 17:31
To
Tom Hughes <to...@co...>
cc
"val...@li..." <val...@li...>, Mogens Lindholdt Lauridsen <ML...@ba...>
Subject
Re: [Valgrind-users] Montavista cross compilation
After I got valgrind to compile, I am having difficulty running.
# ./valgrind
valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux': No such file or directory
-----Original Message-----
From: Tom Hughes [mailto:to...@co...]
Sent: Friday, October 09, 2009 10:57 AM
To: Brandon Rioja
Cc: Mogens Lindholdt Lauridsen; Bart Van Assche; val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
On 09/10/09 15:43, Brandon Rioja wrote:
> I'm getting some problems, still.
>
> This is the error:
>
> /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc
> -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement
> -fno-stack-protector -o memcheck-ppc32-linux -static
> -Wl,-defsym,valt_load_address=0x38000000 -nodefaultlibs -nostartfiles -u
> _start -m32 -Wl,-T,../valt_load_address_ppc32_linux.lds
> memcheck_ppc32_linux-mc_leakcheck.o
> memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o
> memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o
> memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a
> ../VEX/libvex-ppc32-linux.a -lgcc
>
> /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(divdf3.o):
> In function `__divdf3':
>
> /home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/divdf3.c:44:
> undefined reference to `abort'
It looks like your libgcc has references to the abort() function in the
C library but we (deliberately) don't link the with the C library.
libgcc is supposed to be low level support routines for gcc generated
code to call and shouldn't really be calling C library routines like
that as it stops you being able to compile code that doesn't link with
the C library.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!<http://www.compton.nu/>
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Val...@li...<http://p.sf.net/sfu/devconference>
https://lists.sourceforge.net/lists/listinfo/valgrind-users
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
Valgrind-users mailing list
Val...@li...
<http://p.sf.net/sfu/devconference>https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Mogens L. L. <ML...@ba...> - 2009-10-09 21:24:17
|
Had I been a little bit more bright, I would have seen that the
instruction comes from within your Linux system and not your application:
(_dl_catch_error (dl-error.c:160) )
==1012== Process terminating with default action of signal 4 (SIGILL)
==1012== Illegal opcode at address 0x400EC70
==1012== at 0x400EC70: _dl_catch_error (dl-error.c:160)
==1012== by 0x4002CE7: do_preload (rtld.c:804)
==1012== by 0x4005A93: dl_main (rtld.c:1727)
==1012== by 0x401595B: _dl_sysdep_start (dl-sysdep.c:239)
==1012== by 0x4002517: _dl_start_final (rtld.c:323)
==1012== by 0x4002A43: _dl_start (rtld.c:551)
==1012== by 0x40164CF: _start (in /lib/ld-2.5.90.so)
(Which I guess mean valgrind is missing this instruction.)
/Mogens
Brandon Rioja <br...@co...>
09-10-2009 23:16
To
Mogens Lindholdt Lauridsen <ML...@ba...>
cc
"val...@li..."
<val...@li...>
Subject
RE: [Valgrind-users] Montavista cross compilation
I tried compiling a simple program with no altivec support.
ppc_85xx-g++ -mno-altivec test.cpp
???
int main() {
return 0;
}
???
But I get an error on startup. The altivec instruction seems to still
exist.
./valgrind ../../a.out
==1026== Memcheck, a memory error detector
==1026== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1026== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright
info
==1026== Command: ../../a.out
==1026==
disInstr(ppc): declined to decode an AltiVec insn.
disInstr(ppc): unhandled instruction: 0x13CB0321
primary 4(0x4), secondary 801(0x321)
I wrote up an issue about this instruction:
https://bugs.kde.org/show_bug.cgi?id=210028
From: Mogens Lindholdt Lauridsen [mailto:ML...@ba...]
Sent: Friday, October 09, 2009 4:58 PM
To: Brandon Rioja
Cc: val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
>disInstr(ppc): declined to decode an AltiVec insn.
It is an Altivec instruction
I got the same problem, but for my case it was because the PPC I use don't
have altivec support. Valgrind actually helped me here, since I also got
the illigal instruction when running without valgrind, but I didn't know
which instruction caused it.
If your PPC support Altivec, I guess valgrind don't. You might be able to
disable altivec when you build your application, and run your application
with lower performance. (But being able to check your application with
valgrind).
Who and how to add support for Altivec in valgrind, if this is the
problem, I don't know...
/Mogens
Brandon Rioja <br...@co...>
09-10-2009 22:46
To
"val...@li..."
<val...@li...>
cc
Subject
Re: [Valgrind-users] Montavista cross compilation
I am getting an illegal instruction error when running valgrind on a ppc
with montavista.
Does anyone have an idea how I can fix this?
# ./valgrind echo hi
==1012== Memcheck, a memory error detector
==1012== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==1012== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright
info
==1012== Command: echo hi
==1012==
disInstr(ppc): declined to decode an AltiVec insn.
disInstr(ppc): unhandled instruction: 0x13CB0321
primary 4(0x4), secondary 801(0x321)
==1012== valgrind: Unrecognised instruction at address 0x400ec70.
==1012== Your program just tried to execute an instruction that Valgrind
==1012== did not recognise. There are two possible reasons for this.
==1012== 1. Your program has a bug and erroneously jumped to a non-code
==1012== location. If you are running Memcheck and you just saw a
==1012== warning about a bad jump, it's probably your program's fault.
==1012== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1012== i.e. it's Valgrind's fault. If you think this is the case or
==1012== you are not sure, please let us know and we'll try to fix it.
==1012== Either way, Valgrind will now raise a SIGILL signal which will
==1012== probably kill your program.
==1012==
==1012== Process terminating with default action of signal 4 (SIGILL)
==1012== Illegal opcode at address 0x400EC70
==1012== at 0x400EC70: _dl_catch_error (dl-error.c:160)
==1012== by 0x4002CE7: do_preload (rtld.c:804)
==1012== by 0x4005A93: dl_main (rtld.c:1727)
==1012== by 0x401595B: _dl_sysdep_start (dl-sysdep.c:239)
==1012== by 0x4002517: _dl_start_final (rtld.c:323)
==1012== by 0x4002A43: _dl_start (rtld.c:551)
==1012== by 0x40164CF: _start (in /lib/ld-2.5.90.so)
==1012==
==1012== HEAP SUMMARY:
==1012== in use at exit: 0 bytes in 0 blocks
==1012== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1012==
==1012== All heap blocks were freed -- no leaks are possible
==1012==
==1012== For counts of detected and suppressed errors, rerun with: -v
==1012== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 2)
Illegal instruction
From: Mogens Lindholdt Lauridsen [mailto:ML...@ba...]
Sent: Friday, October 09, 2009 4:20 PM
To: Brandon Rioja
Cc: Tom Hughes; val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
Well, I am sure there is a more elegant way... but this is how I handle
it....
When you build your code, the path for the tools will be set inside
valgrind. So if you build valgrind in:
"/home/foo/valgrind"
You must also make sure it is located in the same path on your target.
I guess you can use "strace valgrind .." to actually see where it expects
to find the memcheck file.
You can probably fix this by setting the --bindir/--sbindir/--libexecdir
on configure when you build valgrind. (I can live with using the same path
when building and running target, so I didn't bother to figure these
setting out. Sorry...)
/Mogens
Brandon Rioja <br...@co...>
09-10-2009 17:31
To
Tom Hughes <to...@co...>
cc
"val...@li..."
<val...@li...>, Mogens Lindholdt Lauridsen
<ML...@ba...>
Subject
Re: [Valgrind-users] Montavista cross compilation
After I got valgrind to compile, I am having difficulty running.
# ./valgrind
valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux': No
such file or directory
-----Original Message-----
From: Tom Hughes [mailto:to...@co...]
Sent: Friday, October 09, 2009 10:57 AM
To: Brandon Rioja
Cc: Mogens Lindholdt Lauridsen; Bart Van Assche;
val...@li...
Subject: Re: [Valgrind-users] Montavista cross compilation
On 09/10/09 15:43, Brandon Rioja wrote:
> I'm getting some problems, still.
>
> This is the error:
>
> /opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/ppc_85xx-gcc
> -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement
> -fno-stack-protector -o memcheck-ppc32-linux -static
> -Wl,-defsym,valt_load_address=0x38000000 -nodefaultlibs -nostartfiles -u
> _start -m32 -Wl,-T,../valt_load_address_ppc32_linux.lds
> memcheck_ppc32_linux-mc_leakcheck.o
> memcheck_ppc32_linux-mc_malloc_wrappers.o memcheck_ppc32_linux-mc_main.o
> memcheck_ppc32_linux-mc_translate.o memcheck_ppc32_linux-mc_machine.o
> memcheck_ppc32_linux-mc_errors.o ../coregrind/libcoregrind-ppc32-linux.a
> ../VEX/libvex-ppc32-linux.a -lgcc
>
>
/opt/montavista/cge50/montavista/cge/devkit/ppc/85xx/bin/../lib/gcc/powerpc-montavista-linux-gnuspe/4.2.0/libgcc.a(divdf3.o):
> In function `__divdf3':
>
>
/home/build/BUILD/gcc-4.2.0/objdir/gcc/../../gcc/config/soft-fp/divdf3.c:44:
> undefined reference to `abort'
It looks like your libgcc has references to the abort() function in the
C library but we (deliberately) don't link the with the C library.
libgcc is supposed to be low level support routines for gcc generated
code to call and shouldn't really be calling C library routines like
that as it stops you being able to compile code that doesn't link with
the C library.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|