Re: [Valgrind-developers] debugging valgrind

[Nicholas N. <nj...@ca...>]

On Mon, 30 Aug 2004, Sebastian Biallas wrote:

> Now that the timer code works (thanks for the fast responses!), I have a 
> problem with valgrind itself. The program I work on is also a JIT[1], so it 
> could also be an obscure prefetch queue problem or so, but the program 
> definitely behaves differently when being valgrinded. (I read the 
> "Limitations" section of the documentation, and found nothing that valgrind 
> can't handle self-modifying code, so I assume it can.)

Hmm, then that section of the manual should be changed.

Valgrind can handle dynamically-generated code just fine.  However, if you 
regenerate code over the top of old code (ie. at the same memory 
addresses) Valgrind will not realise the code has changed, and will run 
its old translations, which will be out-of-date.  So you need to use the 
VALGRIND_DISCARD_TRANSLATIONS client request in that case.

> Since my JIT has the nice property, that I can run the translated code and a 
> slower interpreter concurrently and compare the results after each 
> instruction, I was able to spot the problem -- but I don't understand how the 
> code in question could ever be misinterpreted.

Yes, that's a very nice feature to have :)

> On this
> http://developer.kde.org/~sewardj/docs-2.1.2/mc_techdocs.html#mc-techdocs
> page I saw some nice debug output of the translated code of valgrind. Is 
> there a runtime option (like the VALGRIND_XXX macros) to conditionally turn 
> on this debugging output when my program gets near the suspicious code? Or 
> should I use the "--stop-after=" method to narrow down to the BB in question?

--stop-after doesn't exist any more, unfortunately.  Use --trace-codegen 
to get the debug output (try --trace-codegen=10000 to begin with).  That 
prints out all the code;  if you only want some, you can crudely adjust 
the point at which code starts being printed via the 'notrace_until_limit' 
variable in vg_translate.c.

HTH

N