Re: [Valgrind-developers] debugging valgrind

[Sebastian B. <sb...@bi...>]

Nicholas Nethercote wrote:
> 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.

Ok, that explains the problem.

> 
> 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.

Don't know if there is much need for it, but it might be possible to 
make all pages that have PROT_EXEC | PROT_WRITE access read/execute-only 
and trap writes to these pages to automatically detect the situation.

But anyway, I'll test if using VALGRIND_DISCARD_TRANSLATIONS helps.

>> 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.

Well, I don't think it's still necessary since my assumption that 
valgrind can handle the self-modifying code were wrong.

> 
> HTH
> 
> N
> 

Sebastian