|
From: Julian S. <js...@ac...> - 2005-11-12 18:24:00
|
I'm lost I'm afraid. Can you send a specific example of an x86->IR translation and point specifically at the IR artefacts that are a problem. One thing I do know is you can't assume the SP moves only once per bb -- there's no constraints requiring the original producer of the code (gcc) to stick to that. J On Saturday 12 November 2005 18:09, Bryan Meredith wrote: > I can't seem to instrument my way out of it - the (sim)SP update is too > early but there is no way of knowing just how long to hold off before > invalidating the stack. There are also multiple die_stack calls occuring > within a basic block and delaying them is not a good idea - we just end up > in a mess. > > Obviously there is no way that VEX is going to be tweaked this side of 3.1 > but is making the (sim)SP update occur more in sequence something that > would be considered in the future (possibly through a command line switch > or internal function call if the change will break things) ? > > There might be a another way of doing this but it eludes me at the moment > :( > > > Thanks in advance, > Bryan "Brain Murders" Meredith > > On Saturday 12 Nov 2005 14:16, Bryan Meredith wrote: > > Nope - didn't help - exactly the same behaviour. > > > > I'll try something with the instrumentation so I cache the die_stack > > parameters then act on them just before the jump instruction at the block > > end. If there is more than one die_stack call, I'll see what the > > parameters are and if there is a sensible way to handle it. > > > > Bryan "Brain Murders" Meredith > > > > On Saturday 12 Nov 2005 12:13, Julian Seward wrote: > > > Try --vex-iropt-precise-memory-exns=no. The flag is mis-named, but it > > > might do what you want. > > > > > > J > > > > > > On Saturday 12 November 2005 11:21, Bryan Meredith wrote: > > > > I have found the problem. > > > > > > > > Basically, there is a little bit in the documentation for VEX that > > states > > > > > that the simulated PC registers are updated lazily, apart from the > > > > stack pointer which is updated immediately. > > > > > > > > The problem I am having is that when the die_stack function is > > > > called, > > the > > > > > simulated processor registers are not in a consistant state: > > > > > > > > read from stack -> register(real) > > > > move SP (real) > > > > SP(real) -> SP(sim) > > > > call die_stack() > > > > register(real) -> register(sim) > > > > > > > > Because the value on the stack is the last reference to an allocated > > block > > > > > that I am tracking, when die_stack is called, I note that the > > > > reference dies and raise a leak report. However, this is not the last > > > > reference as > > > > if > > > > > > the stack ->reg(real) reg(real)->reg(sim) had occurred, I would have > > > > tracked the value there and not leaked. > > > > > > > > So, two ways of fixing this I think (open to suggestions as ever): > > > > > > > > Tweak VEX so that pending register(sim) updates are flushed before > > > > the SP(sim) is written. > > > > Trap the stack change but don't act until the basic block ends so > > > > that registers(sim) are consistant. > > > > > > > > For the second one to work, I have to assume that the stack pointer > > > > is > > > > only > > > > > > moved up once in a basic block. I havent done any x86 assembler > > previously > > > > > so I dont know how sensible an assumption this is. > > > > > > > > Any help / advice appreciated. > > > > > > > > thanks, > > > > Bryan "Brain Murders" Meredith > > > > > > > > > > > > ------------------------------------------------------- > > > > SF.Net email is sponsored by: > > > > Tame your development challenges with Apache's Geronimo App Server. > > > > Download it for free - -and be entered to win a 42" plasma tv or your > > very > > > > > own Sony(tm)PSP. Click here to play: > > http://sourceforge.net/geronimo.php > > > > > _______________________________________________ > > > > Valgrind-developers mailing list > > > > Val...@li... > > > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > > ------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Tame your development challenges with Apache's Geronimo App Server. > > Download > > > > it for free - -and be entered to win a 42" plasma tv or your very own > > > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > > > _______________________________________________ > > > Valgrind-developers mailing list > > > Val...@li... > > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App Server. > > Download it for free - -and be entered to win a 42" plasma tv or your > > very own Sony(tm)PSP. Click here to play: > > http://sourceforge.net/geronimo.php > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free - -and be entered to win a 42" plasma tv or your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |