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:josef.weidendor...@gmx.de] > Sent: Monday, June 21, 2010 9:27 AM > To: valgrind-users@lists.sourceforge.net > 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 > Valgrind-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/valgrind-users > ------------------------------------------------------------------------------ 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 Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
