|
From: Nicholas N. <nj...@cs...> - 2005-05-02 13:39:41
|
On Mon, 2 May 2005, Duncan Sands wrote: >>> I've hit the valgrind trampoline problem: I need to take >>> the address of a local subroutine, which causes valgrind >>> to barf. The docs say to use VALGRIND_DISCARD_TRANSLATIONS, >>> but don't give much in the way of details. An example of how >>> to do this would be helpful. > > "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. You need to use the VALGRIND_DISCARD_TRANSLATIONS > client request in that case. For the same reason gcc's trampolines for nested > functions are currently unsupported, see bug 69511. " > > I read this as implying that VALGRIND_DISCARD_TRANSLATIONS are needed for > trampolines. Is that wrong? It's a bit subtle; some trampolines will work. The problem will only occur if you put a trampoline on the stack, and then later another trampoline at exactly the same address. In that case, Valgrind will rerun the translation it made for the first trampoline, not realising that it is out of date. If no two trampolines are at the same address, it should work ok. As for using VALGRIND_DISCARD_TRANSLATIONS, I guess after you call a function that uses a trampoline, you should use this macro with an address range that would cover where the trampoline was, eg. start at the address of some local variable and go a few hundred bytes beyond that. I realise this is not a very elegant way to do it. One thing puzzles me: you said valgrind barfs. Can you give the output? This problem shouldn't cause Valgrind to barf, but rather silently run the wrong code. N |