|
From: Nicholas N. <nj...@cs...> - 2005-05-02 18:38:30
|
On Mon, 2 May 2005, Duncan Sands wrote: > 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? If it's the same trampoline, I think it should work. >> 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? No idea, but I'd hope it's small, eg. only a handful of instructions. The good thing is that you can be conservative -- all that will happen is that Valgrind will flush any translations it is holding for that range of addresses, which could possibly slow it down. Try 100 bytes, or 1000, see if that helps. > 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... Right. Unfortunately you've hit a dark corner of Valgrind that doesn't work very well. As the commentary on bug #69511 suggests, we don't have a good solution for this problem, since detecting it would be very expensive. N |