|
From: Duncan S. <bal...@fr...> - 2005-05-02 14:05:01
|
Hi Nicholas, thanks for replying. > > 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. If I have a routine that uses a trampoline, and I call it twice in succession, won't that put the trampolines at the same address and cause a problem? Or will it be the same trampoline, so no problem? > 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. I guess my pointer to the local function is actually a pointer to the trampoline code, so I guess I can use that as the start address. Any idea how much code a trampoline can contain? Does it actually vary depending on the number of local variables used as function arguments? > 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. I said that wrong: my program explodes, valgrind produces a ton of error messages, and everything exits. valgrind is not crashing in any way as far as I can see. I guess the problem is that in the routine in question there are two code paths each of which leads to the address being taken of a (different) local procedure - presumably this is why there are sometimes different trampolines at the same stack address. It is to be expected that the program dies if the wrong one is called... Ciao, Duncan. |