|
From: M B <sup...@go...> - 2008-07-07 14:03:10
|
Hi all, I crosscompiled a c++ application for ppc with g++-3.2 and glibc-2.3.2 and linked it statically (I know linking statically against glibc is bad). Valgrind prints some errors, but doesn't print any symbol names, despite debug information. Valgrind 3.3.1 was natively compiled and linked against glibc-2.3.6. The native c++ compilers (3.3.6; 4.1.2, glibc-2.3.6) and another cross-compiler g++-4.0.0 with uclibc work, but I have to use g++-3.2 for my application. I was able to reproduce this problem with any simple c++ application, but not wit a C application. Any ideas why Valgrind (memcheck) doesn't print symbol names? I build the crosscompiler (3.2) with crosstool, so I can change some options if I did something wrong. Regards Markus |
|
From: Yoni B. <Yo...@ce...> - 2009-01-20 07:00:15
|
Hi I compiled valgrind 3.4.0 for powerpc using Windriver linux environment. I loaded the files to the target and tried to analyize a fully debug information application. Valgrind found some problems but the output did not include any symbol information. The same process worked fine with previous version (3.3.0) I also compiled valgring (3.4.0) to my desktop enviroment (Red Hat) and it worked fine. Did anyone have the same problem? Here is some output of valgrind verbose report on the ppc target: (valgrind aidc.out) where aidc.out is compiled by cross gcc with -g flag) ==8942== Memcheck, a memory error detector. ==8942== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==8942== Using LibVEX rev 1878, a library for dynamic binary translation. ==8942== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==8942== Using valgrind-3.4.0, a dynamic binary instrumentation framework. ==8942== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==8942== --8942-- Command line --8942-- aidc.out --8942-- Startup, with flags: --8942-- -v --8942-- Contents of /proc/version: --8942-- Linux version 2.6.14.7-aidc.1.17 (builder@build-host) (gcc version 3.4.4 (Wind River Linux)) #3 PREEMPT Wed Dec 17 16:08:12 UTC 2008 --8942-- Arch and hwcaps: PPC32, ppc32-int-flt-FX-GX --8942-- Page sizes: currently 4096, max supported 65536 --8942-- Valgrind library directory: /usr/local/lib/valgrind --8942-- Reading syms from /usr/local/lib/valgrind/ppc32-linux/memcheck (0x38000000) --8942-- object doesn't have a dynamic symbol table --8942-- Reading suppressions file: /usr/local/lib/valgrind/default.supp ==8942== Conditional jump or move depends on uninitialised value(s) ==8942== at 0x400224C: (within /lib/ld-2.3.6.so) ==8942== by 0x40101D3: (within /lib/ld-2.3.6.so) ==8942== ==8942== Conditional jump or move depends on uninitialised value(s) ==8942== at 0x400227C: (within /lib/ld-2.3.6.so) ==8942== by 0x40101D3: (within /lib/ld-2.3.6.so) ==8942== ==8942== Conditional jump or move depends on uninitialised value(s) ==8942== at 0x4002368: (within /lib/ld-2.3.6.so) ==8942== by 0x40101D3: (within /lib/ld-2.3.6.so) ==8942== Warning: noted but unhandled ioctl 0x2001000a with no size/direction hints ==8942== This could cause spurious value errors to appear. ==8942== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==8942== Warning: noted but unhandled ioctl 0x2001000f with no size/direction hints ==8942== This could cause spurious value errors to appear. ==8942== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==8942== Warning: noted but unhandled ioctl 0x3001000f with no size/direction hints ==8942== This could cause spurious value errors to appear. ==8942== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper. ==8942== ==8942== Conditional jump or move depends on uninitialised value(s) ==8942== at 0xFB0F1F4: (within /lib/libc-2.3.6.so) ==8942== by 0x10140113: (within /usr/local/sbin/aidc.out) ==8942== by 0xFF7D287: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0xFF7DB6F: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0xFF7B8C3: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0xFF7C3F3: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0xFF74943: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0xFF74D43: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0x1014067B: (within /usr/local/sbin/aidc.out) ==8942== by 0x1014173B: (within /usr/local/sbin/aidc.out) ==8942== by 0x10004143: (within /usr/local/sbin/aidc.out) ==8942== by 0xFAB592B: (within /lib/libc-2.3.6.so) ==8942== ==8942== Conditional jump or move depends on uninitialised value(s) ==8942== at 0xFB0F1FC: (within /lib/libc-2.3.6.so) ==8942== by 0x10140113: (within /usr/local/sbin/aidc.out) ==8942== by 0xFF7D287: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0xFF7DB6F: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0xFF7B8C3: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0xFF7C3F3: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0xFF74943: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0xFF74D43: (within /usr/lib/libexpat.so.0.5.0) ==8942== by 0x1014067B: (within /usr/local/sbin/aidc.out) ==8942== by 0x1014173B: (within /usr/local/sbin/aidc.out) ==8942== by 0x10004143: (within /usr/local/sbin/aidc.out) ==8942== by 0xFAB592B: (within /lib/libc-2.3.6.so) Yoni Baehr |
|
From: Orjan G. <orj...@er...> - 2009-01-22 13:40:22
|
Yoni Baehr <Yoni <at> ceragon.com> writes: > > > Hi > > I compiled valgrind 3.4.0 for powerpc using Windriver linux environment. > I loaded the files to the target and tried to analyize a fully debug > information application. > Valgrind found some problems but the output did not include any symbol > information. > > The same process worked fine with previous version (3.3.0) > > I also compiled valgring (3.4.0) to my desktop enviroment (Red Hat) and > it worked fine. > > Did anyone have the same problem? > > Here is some output of valgrind verbose report on the ppc target: > (valgrind aidc.out) where aidc.out is compiled by cross gcc with -g > flag) > > ==8942== Memcheck, a memory error detector. > ==8942== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. > ==8942== Using LibVEX rev 1878, a library for dynamic binary > translation. > ==8942== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. > ==8942== Using valgrind-3.4.0, a dynamic binary instrumentation > framework. > ==8942== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. > ==8942== > --8942-- Command line > --8942-- aidc.out > --8942-- Startup, with flags: > --8942-- -v > --8942-- Contents of /proc/version: > --8942-- Linux version 2.6.14.7-aidc.1.17 (builder <at> build-host) (gcc > version 3.4.4 (Wind River Linux)) #3 PREEMPT Wed Dec 17 16:08:12 UTC > 2008 > --8942-- Arch and hwcaps: PPC32, ppc32-int-flt-FX-GX > --8942-- Page sizes: currently 4096, max supported 65536 > --8942-- Valgrind library directory: /usr/local/lib/valgrind > --8942-- Reading syms from /usr/local/lib/valgrind/ppc32-linux/memcheck > (0x38000000) > --8942-- object doesn't have a dynamic symbol table > --8942-- Reading suppressions file: /usr/local/lib/valgrind/default.supp > ==8942== Conditional jump or move depends on uninitialised value(s) > ==8942== at 0x400224C: (within /lib/ld-2.3.6.so) > ==8942== by 0x40101D3: (within /lib/ld-2.3.6.so) > ==8942== > ==8942== Conditional jump or move depends on uninitialised value(s) > ==8942== at 0x400227C: (within /lib/ld-2.3.6.so) > ==8942== by 0x40101D3: (within /lib/ld-2.3.6.so) --------------------- I have the exact same problem. Building valgrind 3.4.0 in WindRiver Linux 1.5 environment for ppc8270. Have used valgrind 3.3.0 built in the same way, on the same target without any problem. Standard libraries and the test binary are all with debug symbols. Any input appreciated /Orjan --------------------- Software Designer Platforms & Common Components Ericsson AB ==1329== Memcheck, a memory error detector. ==1329== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==1329== Using LibVEX rev 1878, a library for dynamic binary translation. ==1329== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==1329== Using valgrind-3.4.0, a dynamic binary instrumentation framework. ==1329== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==1329== --1329-- Command line --1329-- ./t --1329-- Startup, with flags: --1329-- -v --1329-- Contents of /proc/version: --1329-- Linux version 2.6.14.7-selinux1-WR1.5ag_cgl (enilsca@seasc0608) (gcc version 3.4.4 (Wind River Linux)) #7 PREEMPT Tue Jan 20 10:51:41 CET 2009 --1329-- Arch and hwcaps: PPC32, ppc32-int-flt-GX --1329-- Page sizes: currently 4096, max supported 65536 --1329-- Valgrind library directory: /opt/valgrind/lib/valgrind --1329-- Reading syms from /opt/valgrind/lib/valgrind/ppc32-linux/memcheck (0x38 000000) --1329-- object doesn't have a dynamic symbol table --1329-- Reading suppressions file: /opt/valgrind/lib/valgrind/default.supp ==1329== Conditional jump or move depends on uninitialised value(s) ==1329== at 0x400224C: (within /lib/ld-2.3.6.so) ==1329== by 0x40101D3: (within /lib/ld-2.3.6.so) ==1329== ==1329== Conditional jump or move depends on uninitialised value(s) ==1329== at 0x400227C: (within /lib/ld-2.3.6.so) ==1329== by 0x40101D3: (within /lib/ld-2.3.6.so) ==1329== ==1329== Conditional jump or move depends on uninitialised value(s) ==1329== at 0x4002368: (within /lib/ld-2.3.6.so) ==1329== by 0x40101D3: (within /lib/ld-2.3.6.so) ==1329== ==1329== Conditional jump or move depends on uninitialised value(s) ==1329== at 0x4013234: (within /lib/ld-2.3.6.so) ==1329== by 0x7EF947F8: ??? ==1329== by 0x4004C13: (within /lib/ld-2.3.6.so) ==1329== by 0x40070F7: (within /lib/ld-2.3.6.so) ==1329== by 0x4001D37: (within /lib/ld-2.3.6.so) ==1329== by 0x400B537: (within /lib/ld-2.3.6.so) ==1329== by 0x4001E6B: (within /lib/ld-2.3.6.so) ==1329== by 0x400402F: (within /lib/ld-2.3.6.so) |
|
From: Nicholas N. <n.n...@gm...> - 2009-01-22 21:16:05
|
On Fri, Jan 23, 2009 at 12:25 AM, Orjan Gustavsson <orj...@er...> wrote: > Yoni Baehr <Yoni <at> ceragon.com> writes: >> >> I compiled valgrind 3.4.0 for powerpc using Windriver linux environment. >> I loaded the files to the target and tried to analyize a fully debug >> information application. >> Valgrind found some problems but the output did not include any symbol >> information. >> >> The same process worked fine with previous version (3.3.0) >> >> I also compiled valgring (3.4.0) to my desktop enviroment (Red Hat) and >> it worked fine. Julian and Tom just fixed a problem related to stack traces which sounds similar, but I thought that was for AMD64 platform only. Maybe try checking out the Valgrind SVN trunk? http://www.valgrind.org/downloads/repository.html Nick |
|
From: Julian S. <js...@ac...> - 2009-01-22 23:07:16
|
> >> I also compiled valgring (3.4.0) to my desktop enviroment (Red Hat) and
> >> it worked fine.
>
> Julian and Tom just fixed a problem related to stack traces which
Tom diagnosed and fixed it. I just sat on the sidelines and felt
vaguely embarrassed at having screwed it up so much :-)
> sounds similar, but I thought that was for AMD64 platform only.
The fix applies to all ELF systems (hence all Linux targets), although
the problem is most obvious on amd64 because that relies entirely on debug
info to unwind the stack. By comparison, on {x86,ppc32,ppc64}-linux, the
stack is self-describing enough to be unwindable without outside assistance.
> Maybe
> try checking out the Valgrind SVN trunk?
> http://www.valgrind.org/downloads/repository.html
Yes, do try that.
J
|
|
From: yoni <Yo...@ce...> - 2009-01-25 10:55:50
|
Hi I loaded the last svn version and compiled it. This time it didn't run at all, and got segmentation fault instantly Here is some gdb output on this : GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc-linux"... (gdb) run aidc.out Starting program: /usr/local/sbin/valgrind aidc.out Executing new program: /usr/local/lib/valgrind/ppc32-linux/memcheck Program received signal SIGILL, Illegal instruction. 0x380303e4 in vgPlain_machine_get_hwcaps () at m_machine.c:453 453 m_machine.c: No such file or directory. in m_machine.c (gdb) bt #0 0x380303e4 in vgPlain_machine_get_hwcaps () at m_machine.c:453 #1 0x38033158 in _start_in_C_linux (pArgc=0x381dfed0) at m_main.c:1392 #2 0x380307dc in _start () It seem the svn is a bit premature, Is it possible to get only the patch concerning the ELF reader ? Bugzilla from js...@ac... wrote: > > >> >> I also compiled valgring (3.4.0) to my desktop enviroment (Red Hat) >> and >> >> it worked fine. >> >> Julian and Tom just fixed a problem related to stack traces which > > Tom diagnosed and fixed it. I just sat on the sidelines and felt > vaguely embarrassed at having screwed it up so much :-) > >> sounds similar, but I thought that was for AMD64 platform only. > > The fix applies to all ELF systems (hence all Linux targets), although > the problem is most obvious on amd64 because that relies entirely on debug > info to unwind the stack. By comparison, on {x86,ppc32,ppc64}-linux, the > stack is self-describing enough to be unwindable without outside > assistance. > >> Maybe >> try checking out the Valgrind SVN trunk? >> http://www.valgrind.org/downloads/repository.html > > Yes, do try that. > > J > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- View this message in context: http://www.nabble.com/valgrind-not-printing-symbol-names-despite-debug-information-included-tp21558085p21650403.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Julian S. <js...@ac...> - 2009-01-25 11:05:22
|
> Program received signal SIGILL, Illegal instruction. > 0x380303e4 in vgPlain_machine_get_hwcaps () at m_machine.c:453 > 453 m_machine.c: No such file or directory. > in m_machine.c This SIGILL is OK. You should tell GDB to pass the signal to Valgrind and continue. Then what happens? > It seem the svn is a bit premature, Is it possible to get only the patch > concerning the ELF reader ? Unrelated problem. J |
|
From: yoni <Yo...@ce...> - 2009-01-25 12:29:39
|
Hi
I ran it again with signal transfered to application:
gdb) handle SIGILL pass nostop
Signal Stop Print Pass to program Description
SIGILL No Yes Yes Illegal instruction
(gdb) run aidc.out
Starting program: /usr/local/sbin/valgrind aidc.out
Executing new program: /usr/local/lib/valgrind/ppc32-linux/memcheck
Program received signal SIGILL, Illegal instruction.
==10303== Memcheck, a memory error detector.
==10303== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
Program received signal SIGSEGV, Segmentation fault.
local_strlen (str=0xc <Address 0xc out of bounds>) at m_debuglog.c:407
407 m_debuglog.c: No such file or directory.
in m_debuglog.c
(gdb) bt
#0 local_strlen (str=0xc <Address 0xc out of bounds>) at m_debuglog.c:407
#1 0x380a97bc in myvprintf_str (send=0x3802d3d8 <add_to_myprintf_buf>,
send_arg2=0x387c5bd0, flags=0, width=0, str=0x4a <Address 0x4a out of
bounds>,
capitalise=0 '\0') at m_debuglog.c:463
#2 0x380a9f7c in vgPlain_debugLog_vprintf (send=0x3802d3d8
<add_to_myprintf_buf>, send_arg2=0x387c5bd0,
format=0x38190c90 "%sUsing LibVEX rev %s, a library for dynamic binary
translation.%s", vargs=0x387c5d50) at m_debuglog.c:742
#3 0x3802d4b4 in vprintf_to_buf (prbuf=<value optimized out>, format=<value
optimized out>, vargs=<value optimized out>) at m_libcprint.c:122
#4 0x3802dc0c in vgPlain_vmessage (kind=Vg_UserMsg, format=0x38190c90
"%sUsing LibVEX rev %s, a library for dynamic binary translation.%s",
vargs=0x387c5d50) at m_libcprint.c:358
#5 0x3802ddb4 in vgPlain_message (kind=<value optimized out>, format=<value
optimized out>) at m_libcprint.c:385
#6 0x38033874 in _start_in_C_linux (pArgc=0x3818f308) at m_main.c:817
#7 0x380307dc in _start ()
(gdb) Quit
Julian Seward-2 wrote:
>
>
>> Program received signal SIGILL, Illegal instruction.
>> 0x380303e4 in vgPlain_machine_get_hwcaps () at m_machine.c:453
>> 453 m_machine.c: No such file or directory.
>> in m_machine.c
>
> This SIGILL is OK. You should tell GDB to pass the signal to Valgrind
> and continue. Then what happens?
>
>> It seem the svn is a bit premature, Is it possible to get only the patch
>> concerning the ELF reader ?
>
> Unrelated problem.
>
> J
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
--
View this message in context: http://www.nabble.com/valgrind-not-printing-symbol-names-despite-debug-information-included-tp21558085p21650695.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.
|
|
From: yoni <Yo...@ce...> - 2009-01-25 12:29:43
|
Hi Sorry, this last one was my mistake. I dont have subversion, I used eclipse plugin. I remove from vex Makefile the subversion line so I got empty VEX/priv/main/vex_svnversion.h, which cause the exception. So svn valgrind worked but the the bad news are that debug symbols are still not displayed. yoni wrote: > > Hi > I ran it again with signal transfered to application: > gdb) handle SIGILL pass nostop > Signal Stop Print Pass to program Description > SIGILL No Yes Yes Illegal instruction > (gdb) run aidc.out > Starting program: /usr/local/sbin/valgrind aidc.out > Executing new program: /usr/local/lib/valgrind/ppc32-linux/memcheck > > Program received signal SIGILL, Illegal instruction. > ==10303== Memcheck, a memory error detector. > ==10303== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. > > Program received signal SIGSEGV, Segmentation fault. > local_strlen (str=0xc <Address 0xc out of bounds>) at m_debuglog.c:407 > 407 m_debuglog.c: No such file or directory. > in m_debuglog.c > (gdb) bt > #0 local_strlen (str=0xc <Address 0xc out of bounds>) at m_debuglog.c:407 > #1 0x380a97bc in myvprintf_str (send=0x3802d3d8 <add_to_myprintf_buf>, > send_arg2=0x387c5bd0, flags=0, width=0, str=0x4a <Address 0x4a out of > bounds>, > capitalise=0 '\0') at m_debuglog.c:463 > #2 0x380a9f7c in vgPlain_debugLog_vprintf (send=0x3802d3d8 > <add_to_myprintf_buf>, send_arg2=0x387c5bd0, > format=0x38190c90 "%sUsing LibVEX rev %s, a library for dynamic binary > translation.%s", vargs=0x387c5d50) at m_debuglog.c:742 > #3 0x3802d4b4 in vprintf_to_buf (prbuf=<value optimized out>, > format=<value optimized out>, vargs=<value optimized out>) at > m_libcprint.c:122 > #4 0x3802dc0c in vgPlain_vmessage (kind=Vg_UserMsg, format=0x38190c90 > "%sUsing LibVEX rev %s, a library for dynamic binary translation.%s", > vargs=0x387c5d50) at m_libcprint.c:358 > #5 0x3802ddb4 in vgPlain_message (kind=<value optimized out>, > format=<value optimized out>) at m_libcprint.c:385 > #6 0x38033874 in _start_in_C_linux (pArgc=0x3818f308) at m_main.c:817 > #7 0x380307dc in _start () > (gdb) Quit > > > > Julian Seward-2 wrote: >> >> >>> Program received signal SIGILL, Illegal instruction. >>> 0x380303e4 in vgPlain_machine_get_hwcaps () at m_machine.c:453 >>> 453 m_machine.c: No such file or directory. >>> in m_machine.c >> >> This SIGILL is OK. You should tell GDB to pass the signal to Valgrind >> and continue. Then what happens? >> >>> It seem the svn is a bit premature, Is it possible to get only the >>> patch >>> concerning the ELF reader ? >> >> Unrelated problem. >> >> J >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> > > -- View this message in context: http://www.nabble.com/valgrind-not-printing-symbol-names-despite-debug-information-included-tp21558085p21651145.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Orjan G. <orj...@er...> - 2009-01-26 09:41:24
|
yoni <Yoni <at> ceragon.com> writes: > > > Hi > Sorry, this last one was my mistake. > I dont have subversion, I used eclipse plugin. I remove from vex Makefile > the subversion line so I got empty > VEX/priv/main/vex_svnversion.h, which cause the exception. > So svn valgrind worked but the the bad news are that debug symbols are still > not displayed. > I'm afraid I have to agree with yoni here, I got the exact same result with SVN-version as with 3.4.0. Trace below. /Örjan ==13059== Memcheck, a memory error detector. ==13059== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==13059== Using LibVEX rev 1882, a library for dynamic binary translation. ==13059== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==13059== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework. ==13059== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==13059== --13059-- Command line --13059-- ls --13059-- Startup, with flags: --13059-- -v --13059-- Contents of /proc/version: --13059-- Linux version 2.6.14.7-selinux1-WR1.5ag_cgl (enilsca@seasc0608) (gcc version 3.4.4 (Wind River Linux)) #1 PREEMPT Fri Jan 23 11:26:29 CET 2009 --13059-- Arch and hwcaps: PPC32, ppc32-int-flt-GX --13059-- Page sizes: currently 4096, max supported 65536 --13059-- Valgrind library directory: /opt/valgrind/lib/valgrind --13059-- Reading syms from /opt/valgrind/lib/valgrind/ppc32-linux/memcheck (0x3 8000000) --13059-- object doesn't have a dynamic symbol table --13059-- Reading suppressions file: /opt/valgrind/lib/valgrind/default.supp ==13059== Conditional jump or move depends on uninitialised value(s) ==13059== at 0x400224C: (within /lib/ld-2.3.6.so) ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) ==13059== ==13059== Conditional jump or move depends on uninitialised value(s) ==13059== at 0x400227C: (within /lib/ld-2.3.6.so) ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) ==13059== ==13059== Conditional jump or move depends on uninitialised value(s) ==13059== at 0x4002368: (within /lib/ld-2.3.6.so) ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) |
|
From: Julian S. <js...@ac...> - 2009-01-26 10:26:54
|
> ==13059== Conditional jump or move depends on uninitialised value(s) > ==13059== at 0x400224C: (within /lib/ld-2.3.6.so) > ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) > ==13059== > ==13059== Conditional jump or move depends on uninitialised value(s) > ==13059== at 0x400227C: (within /lib/ld-2.3.6.so) > ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) > ==13059== > ==13059== Conditional jump or move depends on uninitialised value(s) > ==13059== at 0x4002368: (within /lib/ld-2.3.6.so) > ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) Is this all the errors you get, or just a subset? If a subset, please send the complete set. J |
|
From: yoni <Yo...@ce...> - 2009-01-26 12:54:47
|
The errors description is exactly as the first time. See my first message in this thread. Let me know if you need more - It is a very long list... Julian Seward-2 wrote: > > >> ==13059== Conditional jump or move depends on uninitialised value(s) >> ==13059== at 0x400224C: (within /lib/ld-2.3.6.so) >> ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) >> ==13059== >> ==13059== Conditional jump or move depends on uninitialised value(s) >> ==13059== at 0x400227C: (within /lib/ld-2.3.6.so) >> ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) >> ==13059== >> ==13059== Conditional jump or move depends on uninitialised value(s) >> ==13059== at 0x4002368: (within /lib/ld-2.3.6.so) >> ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) > > Is this all the errors you get, or just a subset? If a subset, please > send the complete set. > > J > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > -- View this message in context: http://www.nabble.com/valgrind-not-printing-symbol-names-despite-debug-information-included-tp21558085p21664628.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: Orjan G. <orj...@er...> - 2009-01-26 12:49:01
|
Julian Seward <jseward <at> acm.org> writes: > > > > ==13059== Conditional jump or move depends on uninitialised value(s) > > ==13059== at 0x400224C: (within /lib/ld-2.3.6.so) > > ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) > > ==13059== > > ==13059== Conditional jump or move depends on uninitialised value(s) > > ==13059== at 0x400227C: (within /lib/ld-2.3.6.so) > > ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) > > ==13059== > > ==13059== Conditional jump or move depends on uninitialised value(s) > > ==13059== at 0x4002368: (within /lib/ld-2.3.6.so) > > ==13059== by 0x40101D3: (within /lib/ld-2.3.6.so) > > Is this all the errors you get, or just a subset? If a subset, please > send the complete set. > > J > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > Uhh, it is a subset, the complete list is 10190 errors, so I guess it is a bit too long to include here. That is from running 'ls', when I run it on a simple 1-liner c program that overruns a stack array, I get 3651 errors from 372 contexts, otherwise almost identical to the 'ls' case. I can send it to you directly if you like. ==1228== IN SUMMARY: 10190 errors from 467 contexts (suppressed: 1675 from 1) /Örjan |
|
From: Shaan <get...@gm...> - 2011-10-27 15:10:28
|
Hi, I have a question How can we install valgrind for WIndriver Linux What are the steps Regards, Shaan |
|
From: Bart V. A. <bar...@gm...> - 2008-07-08 06:38:40
|
On Mon, Jul 7, 2008 at 4:03 PM, M B <sup...@go...> wrote: > I crosscompiled a c++ application for ppc with g++-3.2 and glibc-2.3.2 > and linked it statically (I know linking statically against glibc is > bad). > Valgrind prints some errors, but doesn't print any symbol names, > despite debug information. > Valgrind 3.3.1 was natively compiled and linked against glibc-2.3.6. > The native c++ compilers (3.3.6; 4.1.2, glibc-2.3.6) and another > cross-compiler g++-4.0.0 with uclibc work, but I have to use g++-3.2 > for my application. > > I was able to reproduce this problem with any simple c++ application, > but not wit a C application. > > Any ideas why Valgrind (memcheck) doesn't print symbol names? I build > the crosscompiler (3.2) with crosstool, so I can change some options > if I did something wrong. The format of debug information differs between platforms and between gcc versions. Valgrind can only print symbol names if it has been able to parse the symbol information generated by the compiler. You can verify whether Valgrind has been able to read symbol information by passing the option --trace-symtab=yes to Valgrind. Bart. |