|
From: Robert B. <gm...@re...> - 2010-06-06 15:40:18
|
Hi, I'm trying to get valgrind running with an AMCC PPC kilauea board, ELDK4.2, and a recent kernel. That's what I did so far: svn co svn://svn.valgrind.org/valgrind/trunk valgrind cp dispatch-ppc32-linux.S valgrind/coregrind/m_dispatch (that's a patched version, which gets rid of the altivec instructions) cd valgrind source ../../../env.sh (this sets up my cross environment) ./autogen.sh ./configure --host=powerpc-linux --prefix=$ELDK_PREFIX/eldk-4.2-ppc_4xx/ppc_4xx make it fails like this: mv -f .deps/memcheck_ppc32_linux-mc_translate.Tpo .deps/memcheck_ppc32_linux-mc_translate.Po powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -O2 -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT memcheck_ppc32_linux-mc_machine.o -MD -MP -MF .deps/memcheck_ppc32_linux-mc_machine.Tpo -c -o memcheck_ppc32_linux-mc_machine.o `test -f 'mc_machine.c' || echo './'`mc_machine.c mv -f .deps/memcheck_ppc32_linux-mc_machine.Tpo .deps/memcheck_ppc32_linux-mc_machine.Po powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -O2 -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT memcheck_ppc32_linux-mc_errors.o -MD -MP -MF .deps/memcheck_ppc32_linux-mc_errors.Tpo -c -o memcheck_ppc32_linux-mc_errors.o `test -f 'mc_errors.c' || echo './'`mc_errors.c mv -f .deps/memcheck_ppc32_linux-mc_errors.Tpo .deps/memcheck_ppc32_linux-mc_errors.Po ../coregrind/link_tool_exe 0x38000000 powerpc-linux-gcc -Wno-long-long -Wno-pointer-sign -fno-stack-protector -o memcheck-ppc32-linux -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -O2 -static -nodefaultlibs -nostartfiles -u _start -m32 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/link_tool_exe: ../coregrind/link_tool_exe: cannot execute binary file make[3]: *** [memcheck-ppc32-linux] Error 126 make[3]: Leaving directory `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind/memcheck' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind/memcheck' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind' make: *** [all] Error 2 The link_tool_exe is a ppc executable, so it can not be executed by my x86 host. When I try not to build on my host but directly on my target it fails because it does not find the aclocal. Please advise. Regards, Robert -- Robert Berger Embedded Software Specialist Reliable Embedded Systems Consulting Training Engineering Tel.: (+30) 697 593 3428 Fax.:(+30) 210 684 7881 URL: http://www.reliableembeddedsystems.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- ..."It is always easier to ask forgiveness than it is to get permission." - (Amazing) Grace Hopper My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1 |
|
From: Julian S. <js...@ac...> - 2010-06-06 20:19:09
|
Oh, darn. It looks like I broke cross compilation recently by introducing link_tool_exe.c as part of the build process. Honestly .. the your best bet is to rewrite link_tool_exe.c as a perl script, so it can run on the host. I actually started out to write it as a perl script, but couldn't find a way to make it portably do 64-bit arithmetic, which it needs to do on some platforms. Hence I wimped out and wrote a C program instead. However, that evidently isn't going to work in this case. J On Sunday 06 June 2010, Robert Berger wrote: > Hi, > > I'm trying to get valgrind running with an AMCC PPC kilauea board, > ELDK4.2, and a recent kernel. > > That's what I did so far: > svn co svn://svn.valgrind.org/valgrind/trunk valgrind > cp dispatch-ppc32-linux.S valgrind/coregrind/m_dispatch > (that's a patched version, which gets rid of the altivec instructions) > cd valgrind > source ../../../env.sh > (this sets up my cross environment) > ./autogen.sh > ./configure --host=powerpc-linux > --prefix=$ELDK_PREFIX/eldk-4.2-ppc_4xx/ppc_4xx > make > > it fails like this: > mv -f .deps/memcheck_ppc32_linux-mc_translate.Tpo > .deps/memcheck_ppc32_linux-mc_translate.Po > powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include > -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -m32 -O2 > -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith > -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length > -fno-strict-aliasing -O2 -Wno-long-long -Wno-pointer-sign > -fno-stack-protector -MT memcheck_ppc32_linux-mc_machine.o -MD -MP -MF > .deps/memcheck_ppc32_linux-mc_machine.Tpo -c -o > memcheck_ppc32_linux-mc_machine.o `test -f 'mc_machine.c' || echo > './'`mc_machine.c > mv -f .deps/memcheck_ppc32_linux-mc_machine.Tpo > .deps/memcheck_ppc32_linux-mc_machine.Po > powerpc-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include > -I../VEX/pub -DVGA_ppc32=1 -DVGO_linux=1 -DVGP_ppc32_linux=1 -m32 -O2 > -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith > -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length > -fno-strict-aliasing -O2 -Wno-long-long -Wno-pointer-sign > -fno-stack-protector -MT memcheck_ppc32_linux-mc_errors.o -MD -MP -MF > .deps/memcheck_ppc32_linux-mc_errors.Tpo -c -o > memcheck_ppc32_linux-mc_errors.o `test -f 'mc_errors.c' || echo > './'`mc_errors.c > mv -f .deps/memcheck_ppc32_linux-mc_errors.Tpo > .deps/memcheck_ppc32_linux-mc_errors.Po > ../coregrind/link_tool_exe 0x38000000 powerpc-linux-gcc -Wno-long-long > -Wno-pointer-sign -fno-stack-protector -o memcheck-ppc32-linux -m32 > -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith > -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length > -fno-strict-aliasing -O2 -static -nodefaultlibs -nostartfiles -u _start > -m32 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/link_tool_exe: ../coregrind/link_tool_exe: cannot execute > binary file > make[3]: *** [memcheck-ppc32-linux] Error 126 > make[3]: Leaving directory > `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind/memcheck' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind/memcheck' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/home/rber/projects/ldd/ldd_for_trainer/src/30_valgrind/valgrind' > make: *** [all] Error 2 > > The link_tool_exe is a ppc executable, so it can not be executed by my > x86 host. > When I try not to build on my host but directly on my target it fails > because it does not find the aclocal. > > Please advise. > > Regards, > > Robert |
|
From: Tom H. <to...@co...> - 2010-06-06 23:42:16
|
On 06/06/10 21:41, Julian Seward wrote: > Honestly .. the your best bet is to rewrite link_tool_exe.c as > a perl script, so it can run on the host. I actually started out > to write it as a perl script, but couldn't find a way to make it > portably do 64-bit arithmetic, which it needs to do on some platforms. > Hence I wimped out and wrote a C program instead. However, that > evidently isn't going to work in this case. Probably best just to use Math::BigInt then you can do arbitrary precision integer arithmetic regardless of the underlying platform. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Bart V. A. <bva...@ac...> - 2010-06-07 06:06:47
|
On Sun, Jun 6, 2010 at 10:41 PM, Julian Seward <js...@ac...> wrote: > Oh, darn. It looks like I broke cross compilation recently by > introducing link_tool_exe.c as part of the build process. > > Honestly .. the your best bet is to rewrite link_tool_exe.c as > a perl script, so it can run on the host. I actually started out > to write it as a perl script, but couldn't find a way to make it > portably do 64-bit arithmetic, which it needs to do on some platforms. > Hence I wimped out and wrote a C program instead. However, that > evidently isn't going to work in this case. Why Perl ? Perl isn't used anywhere yet during the Valgrind build -- that would introduce an additional dependency. Bash can do 64-bit arithmetic as well. An example: $ bash -c 'echo $((1<<62))' 4611686018427387904 Bart. |
|
From: Julian S. <js...@ac...> - 2010-06-07 06:23:19
|
> Why Perl ? Perl isn't used anywhere yet during the Valgrind build -- > that would introduce an additional dependency. It just seems convenient, plus it is already a dependency and is checked for by the configure script. Some of the analysis scripts for Cachegrind and Massif are written in Perl (cg_annotate, ms_print), and maybe some others. > Bash can do 64-bit arithmetic as well. An example: > > $ bash -c 'echo $((1<<62))' > 4611686018427387904 Hmm, true. What about dash though? J |
|
From: Julian S. <js...@ac...> - 2010-06-07 05:53:33
|
> Probably best just to use Math::BigInt then you can do arbitrary > precision integer arithmetic regardless of the underlying platform. Is Math::BigInt is supported as standard in Perl? and also, in older Perls? Obviously if the build process is going to rely on it then it needs to be available on all perls we could reasonably expect to encounter. J |
|
From: Tom H. <to...@co...> - 2010-06-07 07:48:17
|
On 07/06/10 07:15, Julian Seward wrote: >> Probably best just to use Math::BigInt then you can do arbitrary >> precision integer arithmetic regardless of the underlying platform. > > Is Math::BigInt is supported as standard in Perl? and also, in older > Perls? Obviously if the build process is going to rely on it then > it needs to be available on all perls we could reasonably expect to > encounter. Since at least 5.005 yes, and if you've got a system with anything older than that then you already have serious pain as that was released in July 1998. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Julian S. <js...@ac...> - 2010-06-12 19:48:45
|
On Monday, June 07, 2010, Tom Hughes wrote:
> On 07/06/10 07:15, Julian Seward wrote:
> >> Probably best just to use Math::BigInt then you can do arbitrary
> >> precision integer arithmetic regardless of the underlying platform.
> >
> > Is Math::BigInt is supported as standard in Perl? and also, in older
> > Perls? Obviously if the build process is going to rely on it then
> > it needs to be available on all perls we could reasonably expect to
> > encounter.
>
> Since at least 5.005 yes, and if you've got a system with anything older
> than that then you already have serious pain as that was released in
> July 1998.
Hmm, doesn't work with the stock perl on redhat9 (prehistoric, I know,
but certainly post-dates perl 5.005). Am I doing something wrong?
J
$ uname -a
Linux redhat9 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386
GNU/Linux
$ perl --version
This is perl, v5.8.0 built for i386-linux-thread-multi
(with 1 registered patch, see perl -V for more detail)
$ cat ascript.pl
#! /usr/bin/perl
use Math::BigInt;
use strict;
my $x = hex( @ARGV[0] );
printf("result = %x %x\n", $x, $x - 0x800000);
$ ./ascript.pl 0x138000000
Integer overflow in hexadecimal number at ./ascript.pl line 6.
result = ffffffff ffffffff
|
|
From: Tom H. <to...@co...> - 2010-06-12 22:59:33
|
On 12/06/10 20:48, Julian Seward wrote:
> Hmm, doesn't work with the stock perl on redhat9 (prehistoric, I know,
> but certainly post-dates perl 5.005). Am I doing something wrong?
Don't you need to explicitly make $x a Math::BigInt?
> $ cat ascript.pl
> #! /usr/bin/perl
>
> use Math::BigInt;
> use strict;
>
> my $x = hex( @ARGV[0] );
I think this needs to me:
my $x = Math::BigInt->from_hex( $ARGV[0] );
> printf("result = %x %x\n", $x, $x - 0x800000);
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: Robert B. <gm...@re...> - 2010-06-07 14:42:36
|
Hi all, Just let me know when you have something for me to test. Regards, Robert -- Robert Berger Embedded Software Specialist Reliable Embedded Systems Consulting Training Engineering Tel.: (+30) 697 593 3428 Fax.:(+30) 210 684 7881 URL: http://www.reliableembeddedsystems.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- ..."Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth, in a memo to Peter Van Emde Boas titled "Notes on the van Emde Boas construction of priority deques: An instructive use of recursion" My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1 |
|
From: Satya V. G. <gup...@ne...> - 2010-06-16 12:07:37
|
I made the suggested change (bumped up the Stack size to 512 pages instead of the 16) and continue to have another problem. I have only 256MB RAM in my device and when I bumped up the stack to 512 pages as suggested, all processes go to sleep. The change in stack size obviously changed the behavior of Valgrind. The original problem I had was that VG_(strcmp) in callgrind caused a SIGSEGV. The reason it was suggested that I bump up the stack size was that Boost libraries use very long names. In my mind, I am better off limiting the size of the two strings that are offered to VG_(strcmp) to some MAX_STRING_SIZE instead of increasing the stack size. However, I do not know what is a reasonable value for MAX_STRING_SIZE? Does anyone have a suggestion on what size I should use here? Thanks SVG -----Original Message----- From: bar...@gm... [mailto:bar...@gm...] On Behalf Of Bart Van Assche Sent: Sunday, June 13, 2010 6:06 AM To: Satya V. Gupta Cc: val...@li... Subject: Re: [Valgrind-users] Running Valgrind on ELF/ python/ boost based executables On Sun, Jun 13, 2010 at 11:47 AM, Satya V. Gupta <gup...@ne...> wrote: > I have a supervisory process that is kicked off by an ELF executable > which in turn invokes some ELF/ python script/ executables based child processes. > I wish to run valgrind with --tool=callgrind and be able to inject > valgrind into all processes. So far I have tried to run the > supervisory process with --trace-children=yes and of course --tool=callgrind switches. > > Any ELF based executable process stays up but valgrind receives a > SIGSEGV from all the others. It leaves behind an identical call stack > strace with a bunch of exception handlers that pass through the main > python executable and a bunch of boost libraries. > > Does anyone have recommendations on how to run python/ boost based > executable? Instead of asking the same question twice, you should try the suggestion that was posted in reply to your message on the valgrind-developers mailing list (see also http://sourceforge.net/mailarchive/forum.php?thread_name=201006122144.03178. jseward%40acm.org&forum_name=valgrind-developers). Bart. ____________________________________________________________ Get Free Email with Video Mail & Video Chat! http://www.netzero.net/freeemail?refcd=NZTAGOUT1FREM0210 |
|
From: Satya V. G. <gup...@ne...> - 2010-06-17 11:04:55
|
Josef, Since you asked, I ran Valgrind with --demangle=no; the SIGSEGV issue I saw earlier went away. However, I had gone to great lengths to insert symbol information into my image in order to chase down a run time issue I am having with the code. Therefore, while running with --demangle=no is a good experiment, it is not a practical option for me. Is there another way in valgrind to restrict the string size offered to VG_(strcmp)() so that it won't crash? Can there be canary protection around the valgrind stack to protect it from being overrun in situations like these? Just to confirm, my code runs fine with both (--tool=none) or (--tool=callgrind --demangle=no). Since I have a space crunch, I took out cachegrind from the valgrind binaries I placed on my target file system. Therefore, to answer your question on cache simulator, I don't believe I am running cachesimulator. Turning callgrind on interactively is not a valid option since I am chasing a run time crash and I don't know where the "interesting" piece(s) of code actually are. For some legacy reason that no one here is clear about, the file system is read-only; so I don't get a core-dump when the code crashes. To overcome this read-only file system limitation, I have made a small change in the callgrind code so that it will redirect the file descriptor which callgrind uses to write its data, to the valgrind-listener socket instead. I have also made small changes to the valgrind-listener code to write the data it receives, to disk instead of on stdout. Therefore, in essence, I am using valgrind --tool=callgrind as a "coredump" instead. So far it seems to be working fine except for the long function name issue. I am perfectly fine if all I saw was 100 bytes (and maybe even less) of the function name. That many bytes will be quite enough for me to make out the exact function I am targeting. So I shall greatly appreciate your help on resolving the VG_(strcmp) issue with long names. Thanks SVG -----Original Message----- From: Josef Weidendorfer [mailto:Jos...@gm...] Sent: Wednesday, June 16, 2010 1:56 PM To: val...@li... Cc: Satya V. Gupta Subject: Re: [Valgrind-users] Running Valgrind on ELF/ python/ boost based executables On Wednesday 16 June 2010, Satya V. Gupta wrote: > I made the suggested change (bumped up the Stack size to 512 pages > instead of the 16) and continue to have another problem. If it really is a problem with the tools stack size, instead of increasing to 512 pages, you can also run with "--demangle=no". This will not call into the C++ symbol demangler, which is the only part that needs large stack sizes. > I have only 256MB RAM in my device and when I bumped up the stack to > 512 pages as suggested, all processes go to sleep. The change in stack > size obviously changed the behavior of Valgrind. > > The original problem I had was that VG_(strcmp) in callgrind caused a > SIGSEGV. The reason it was suggested that I bump up the stack size was > that Boost libraries use very long names. > > In my mind, I am better off limiting the size of the two strings that > are offered to VG_(strcmp) to some MAX_STRING_SIZE instead of > increasing the stack size. However, I do not know what is a reasonable > value for MAX_STRING_SIZE? Does anyone have a suggestion on what size > I should use here? Does your code run with "--tool=none" on that device at all? Do you run with cache simulator on or off (off is better for memory usage)? Instead of playing around with strings used only once, you are better off restricting the number of cost counters in Callgrind: e.g. you could switch on instrumentation only when running the interesting parts of your code, see the macro CALLGRIND_START_INSTRUMENTATION defined in callgrind.h (to be used in the *client code*). Josef > > Thanks > > SVG > > -----Original Message----- > From: bar...@gm... [mailto:bar...@gm...] On > Behalf Of Bart Van Assche > Sent: Sunday, June 13, 2010 6:06 AM > To: Satya V. Gupta > Cc: val...@li... > Subject: Re: [Valgrind-users] Running Valgrind on ELF/ python/ boost > based executables > > On Sun, Jun 13, 2010 at 11:47 AM, Satya V. Gupta > <gup...@ne...> > wrote: > > I have a supervisory process that is kicked off by an ELF executable > > which in turn invokes some ELF/ python script/ executables based > > child > processes. > > I wish to run valgrind with --tool=callgrind and be able to inject > > valgrind into all processes. So far I have tried to run the > > supervisory process with --trace-children=yes and of course > --tool=callgrind switches. > > > > Any ELF based executable process stays up but valgrind receives a > > SIGSEGV from all the others. It leaves behind an identical call > > stack strace with a bunch of exception handlers that pass through > > the main python executable and a bunch of boost libraries. > > > > Does anyone have recommendations on how to run python/ boost based > > executable? > > Instead of asking the same question twice, you should try the > suggestion that was posted in reply to your message on the > valgrind-developers mailing list (see also > http://sourceforge.net/mailarchive/forum.php?thread_name=201006122144.03178. > jseward%40acm.org&forum_name=valgrind-developers). > > Bart. > > > > > ____________________________________________________________ > Get Free Email with Video Mail & Video Chat! > http://www.netzero.net/freeemail?refcd=NZTAGOUT1FREM0210 > > ---------------------------------------------------------------------- > -------- ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental > unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > ____________________________________________________________ TODAY: iPads for $123.74? Alert: iPads are being auctioned on SwipeBids.com for 95% off today! http://thirdpartyoffers.netzero.net/TGL3241/4c1a01381c9064642b9st02vuc |
|
From: Julian S. <js...@ac...> - 2010-06-17 11:55:44
|
> However, I had gone to great lengths to insert symbol information into my > image in order to chase down a run time issue I am having with the code. > Therefore, while running with --demangle=no is a good experiment, it is not > a practical option for me. Why? You can always postprocess output with c++filt to recover the original C++ names. > Turning callgrind on interactively is not a valid option since I am chasing > a run time crash You are trying to chase down a crash? Wouldn't --tool=memcheck be a more suitable tool for that? If you can use memcheck, then you can send all its output to a network socket using the --log-socket option, so there will be no need to write a log file. J |
|
From: Satya V. G. <gup...@ne...> - 2010-06-23 00:05:09
|
Josef/ Julian The problem I have with --demangle=no is that: a) I am using Python to generate code dynamically and therefore, I don't know of a good way of mapping symbols to addresses in a post processing cycle. At every boot up cycle, the symbol name to address location appears to be vastly different. b) My device runs into either an out of memory situation or ends up in a SIGSEGV crash. As a result, no post processing method for recovering symbols comes to my mind. Given these circumstances, if you are aware of any clever method of recovering the symbols for dynamically generated code, please do let me know and I shall gladly implement your suggestion. SVG -----Original Message----- From: Josef Weidendorfer [mailto:Jos...@gm...] Sent: Monday, June 21, 2010 9:27 AM To: val...@li... Cc: Satya V. Gupta Subject: Re: [Valgrind-users] Running Valgrind on ELF/ python/ boost based executables On Thursday 17 June 2010, Satya V. Gupta wrote: > Since you asked, I ran Valgrind with --demangle=no; the SIGSEGV issue > I saw earlier went away. Very good. > However, I had gone to great lengths to insert symbol information into > my image in order to chase down a run time issue I am having with the code. > Therefore, while running with --demangle=no is a good experiment, it > is not a practical option for me. I have the exact same question as Julian here: what is your problem with "--demangle=no"? It does not cut down any functionality. Symbols will just show up demangled, which you can cope with in a postprocessing step afterwards. > Is there another way in valgrind to restrict the string size offered > to VG_(strcmp)() so that it won't crash? Can there be canary > protection around the valgrind stack to protect it from being overrun > in situations like these? For practical reasons, this seems next to impossible for me. Josef ____________________________________________________________ TODAY: MacBooks for $24.78? Special Report: Apple MacBooks are being auctionned at 85% off! http://thirdpartyoffers.netzero.net/TGL3241/4c214fa46844849c983st04vuc |
|
From: Satya V. G. <gup...@ne...> - 2010-06-23 10:34:05
|
Josef, > What has this to do with "--demangle=no"? Even with "--demangle=no" (which makes a difference only for C++ symbols anyway), symbols should be printed > out just fine. With --demangle=yes, Valgrind almost immediately ends up with a SIGSEGV and reports a problem with VG_(strcmp). With --demangle=no, Valgrind chugs along without generating a SIGSEGV. Since I use boost, python does dynamically generate very long C++ symbols (in some cases they fill up 5 lines). > As just mentioned, "--demangle=no" does not switch off the mapping of addresses to symbols, or influence this in any way. It is just about "pretty > printing" the symbols. With --demangle=yes, Valgrind generates a SIGSEGV almost immediately in VG_(strcmp) and with --demangle=no, it doesn't. "Pretty" symbols would have helped me get closer to a solution to my problem, but "ugly" symbols are not very helpful. > If your symbols do not show up with "--demangle=no", they also would not show up with "--demangle=yes". Actually, I do not think that Valgrind can map > symbols for dynamically generated code at all. I do get some symbol names that sometimes span multiple lines. In some cases, they show up with a substring "boost" in the very long symbol names. > Hmm. I even do not know how this should work. How does in work with GDB? I haven't used GDB yet. I will give that a shot today. SVG -----Original Message----- From: Josef Weidendorfer [mailto:Jos...@gm...] Sent: Wednesday, June 23, 2010 5:37 AM To: val...@li... Cc: Satya V. Gupta Subject: Re: [Valgrind-users] Running Valgrind on ELF/ python/ boost based executables On Wednesday 23 June 2010, Satya V. Gupta wrote: > Josef/ Julian > > The problem I have with --demangle=no is that: > > a) I am using Python to generate code dynamically and therefore, I > don't know of a good way of mapping symbols to addresses in a post > processing cycle. At every boot up cycle, the symbol name to address > location appears to be vastly different. What has this to do with "--demangle=no"? Even with "--demangle=no" (which makes a difference only for C++ symbols anyway), symbols should be printed out just fine. > b) My device runs into either an out of memory situation or ends up in > a SIGSEGV crash. As a result, no post processing method for recovering > symbols comes to my mind. As just mentioned, "--demangle=no" does not switch off the mapping of addresses to symbols, or influence this in any way. It is just about "pretty printing" the symbols. > Given these circumstances, if you are aware of any clever method of > recovering the symbols for dynamically generated code, please do let > me know and I shall gladly implement your suggestion. If your symbols do not show up with "--demangle=no", they also would not show up with "--demangle=yes". Actually, I do not think that Valgrind can map symbols for dynamically generated code at all. Hmm. I even do not know how this should work. How does in work with GDB? For Valgrind, we could introduce a client request notifying VG about any new generated code in the client, together with symbol names. Josef > > SVG > > > -----Original Message----- > From: Josef Weidendorfer [mailto:Jos...@gm...] > Sent: Monday, June 21, 2010 9:27 AM > To: val...@li... > Cc: Satya V. Gupta > Subject: Re: [Valgrind-users] Running Valgrind on ELF/ python/ boost > based executables > > On Thursday 17 June 2010, Satya V. Gupta wrote: > > Since you asked, I ran Valgrind with --demangle=no; the SIGSEGV > > issue I saw earlier went away. > > Very good. > > > However, I had gone to great lengths to insert symbol information > > into my image in order to chase down a run time issue I am having > > with the > code. > > Therefore, while running with --demangle=no is a good experiment, it > > is not a practical option for me. > > I have the exact same question as Julian here: what is your problem > with "--demangle=no"? It does not cut down any functionality. Symbols > will just show up demangled, which you can cope with in a > postprocessing step afterwards. > > > Is there another way in valgrind to restrict the string size offered > > to VG_(strcmp)() so that it won't crash? Can there be canary > > protection around the valgrind stack to protect it from being > > overrun in situations like these? > > For practical reasons, this seems next to impossible for me. > > Josef > > > > ____________________________________________________________ > TODAY: MacBooks for $24.78? > Special Report: Apple MacBooks are being auctionned at 85% off! > http://thirdpartyoffers.netzero.net/TGL3241/4c214fa46844849c983st04vuc > > ---------------------------------------------------------------------- > -------- ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental > unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > ____________________________________________________________ Get Free Email with Video Mail & Video Chat! http://www.netzero.net/freeemail?refcd=NZTAGOUT1FREM0210 |
|
From: Julian S. <js...@ac...> - 2010-06-23 10:46:00
|
> With --demangle=yes, Valgrind generates a SIGSEGV almost immediately in > VG_(strcmp) and with --demangle=no, it doesn't. "Pretty" symbols would have > helped me get closer to a solution to my problem, but "ugly" symbols are > not very helpful. Just to make this very clear: you can convert an "ugly" symbol to a "pretty" one afterwards, by dumping them in a text file and sending it through the c++filt program. J |
|
From: Satya V. G. <gup...@ne...> - 2010-06-23 11:00:57
|
Julian, Thanks - I am unfamiliar with c++filt - I will educate myself on it. Would you happen to know if c++filt requires the instrumented process to be running in order for it to do the translation? Or is the required information already present in the Valgrind trace for c++filt to do this translation independently? My device ends up in an "out of memory" situation soon with Valgrind running - so if c++filt needs the process to be up then I wouldn't know how to get c++filt that information. Thanks SVG -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: Wednesday, June 23, 2010 6:46 AM To: Satya V. Gupta Cc: val...@li...; 'Josef Weidendorfer' Subject: Re: [Valgrind-users] Running Valgrind on ELF/ python/ boost based executables > With --demangle=yes, Valgrind generates a SIGSEGV almost immediately > in > VG_(strcmp) and with --demangle=no, it doesn't. "Pretty" symbols would > have helped me get closer to a solution to my problem, but "ugly" > symbols are not very helpful. Just to make this very clear: you can convert an "ugly" symbol to a "pretty" one afterwards, by dumping them in a text file and sending it through the c++filt program. J ____________________________________________________________ Refinance Now 4.0% FIXED! $160,000 Mortgage for $633/mo. Free. No Obligation. Get 4 Quotes! http://thirdpartyoffers.netzero.net/TGL3241/4c21e93d5fe0348f503st03vuc |
|
From: Dave G. <go...@mc...> - 2010-06-23 14:24:37
|
On Jun 23, 2010, at 5:59 AM CDT, Satya V. Gupta wrote: > Would you happen to know if c++filt requires the instrumented process to be > running in order for it to do the translation? Or is the required > information already present in the Valgrind trace for c++filt to do this > translation independently? My device ends up in an "out of memory" situation > soon with Valgrind running - so if c++filt needs the process to be up then I > wouldn't know how to get c++filt that information. No. It is purely a mechanical transformation that is applied to the text strings: -----8<----- % c++filt __ZN3MPI4File11Read_at_allExPviRKNS_8DatatypeE MPI::File::Read_at_all(long long, void*, int, MPI::Datatype const&) -----8<----- It has nothing to do with the executable or process or debug info. -----8<----- c++filt __ZN1I4MADE4this2UpEi I::MADE::this::Up(int) -----8<----- -Dave |