|
From: Bryan M. <om...@br...> - 2005-11-11 22:03:08
|
Hi Chaps, I need to be able to see writes to spill registers. I can trap writes to memory and the shadow processor registers but I cant work out how to trap writes to the spill registers. Can someone point me at the relevent bit of documentation or provide a small sample of instrumentation please? The basic state of Omega at the moment is that it mostly works but it tends to declare a leak and then out of nowhere, a new reference pops up (which is kind of annoying). I added some instrumentation so I could see loads and right before the last reference on the stack goes out of scope, there is a load of the contents. Unfortunately, I cant see where the data is stored but I suspect that it is going into a spill register as it doesn't get written into a memory location nor any shadow processor register. This typically happens with C++ code - at least I haven't seen it occur with pure C but I am still running a limited set of apps in order to test. I can post debug output if it would help. Thanks in advance, Bryan "Brain Murders" Meredith |
|
From: Nicholas N. <nj...@cs...> - 2005-11-11 23:44:25
|
On Fri, 11 Nov 2005, Bryan Meredith wrote: > I need to be able to see writes to spill registers. > > I can trap writes to memory and the shadow processor registers but I cant work > out how to trap writes to the spill registers. > > Can someone point me at the relevent bit of documentation or provide a small > sample of instrumentation please? > > The basic state of Omega at the moment is that it mostly works but it tends to > declare a leak and then out of nowhere, a new reference pops up (which is > kind of annoying). I added some instrumentation so I could see loads and > right before the last reference on the stack goes out of scope, there is a > load of the contents. Unfortunately, I cant see where the data is stored but > I suspect that it is going into a spill register as it doesn't get written > into a memory location nor any shadow processor register. This typically > happens with C++ code - at least I haven't seen it occur with pure C but I am > still running a limited set of apps in order to test. I'm missing something... what do you mean by "spill registers"? Do you mean spills introduced by Valgrind's code generator? N |
|
From: Bryan M. <om...@br...> - 2005-11-11 23:58:35
|
On Friday 11 Nov 2005 23:44, Nicholas Nethercote wrote: > On Fri, 11 Nov 2005, Bryan Meredith wrote: > > > I need to be able to see writes to spill registers. > > > > I can trap writes to memory and the shadow processor registers but I cant work > > out how to trap writes to the spill registers. > > > > Can someone point me at the relevent bit of documentation or provide a small > > sample of instrumentation please? > > > > The basic state of Omega at the moment is that it mostly works but it tends to > > declare a leak and then out of nowhere, a new reference pops up (which is > > kind of annoying). I added some instrumentation so I could see loads and > > right before the last reference on the stack goes out of scope, there is a > > load of the contents. Unfortunately, I cant see where the data is stored but > > I suspect that it is going into a spill register as it doesn't get written > > into a memory location nor any shadow processor register. This typically > > happens with C++ code - at least I haven't seen it occur with pure C but I am > > still running a limited set of apps in order to test. > > I'm missing something... what do you mean by "spill registers"? Do you > mean spills introduced by Valgrind's code generator? > > N > Yes - there is a memory load into a temporary register. Once that happens, I dont see the value it holds until it is put into a processor register on the simulated cpu. I can only assume that it is being stored in the "spills" area. I need to be able to track this as it is the final live reference to an allocated block and without it, I raise a false leak alert as the stack pointer is moved between the load and the put (then sheepishly free the block later when the code calls free()). Bryan "Brain Murders" Meredith |
|
From: Josef W. <Jos...@gm...> - 2005-11-12 01:26:34
|
On Saturday 12 November 2005 00:58, Bryan Meredith wrote: > Yes - there is a memory load into a temporary register. Once that happens, I > dont see the value it holds until it is put into a processor register on the > simulated cpu. I can only assume that it is being stored in the "spills" > area. I need to be able to track this as it is the final live reference to an > allocated block and without it, I raise a false leak alert as the stack > pointer is moved between the load and the put (then sheepishly free the block > later when the code calls free()). Example please. I suppose the problem must be visible in VEX code. Josef |
|
From: Bryan M. <om...@br...> - 2005-11-12 11:21:56
|
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 |
|
From: Julian S. <js...@ac...> - 2005-11-12 12:12:14
|
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 |
|
From: Bryan M. <om...@br...> - 2005-11-12 14:17:12
|
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 > |
|
From: Bryan M. <om...@br...> - 2005-11-12 18:09:48
|
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 > |
|
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 |
|
From: Bryan M. <om...@br...> - 2005-11-12 19:00:34
|
Here we go: . . . --13048-- o_omegaLoadTracker(0xBEBD4350, 0x5F7CAB0) ## Loads from stack --13048-- o_omegaDetector(0x10, 0xBEBD4354) ## Bumps (sim)ESP --13048-- killing range 0x4 bytes from 0xBEBD4350 ## Die Stack --13048-- o_removeMemBlockReference tp=0xBEBD4350, mb=0x5F7CAB0 --13048-- Removing tracked pointer at 0xBEBD4350 pointing to 0x5F7CAB0 ## lose reference on the stack ==13048== Leaking block of 8(0x8) bytes ## last one so we leak ==13048== at 0x401BA2D: operator new(unsigned) (vg_replace_malloc.c:164) ==13048== by 0x502F006: QString::QString(char const*) (in /usr/lib/qt3/lib/libqt-mt.so.3.2.3) ==13048== Block at 0x5F7CAB0 allocated ==13048== at 0x401BE32: operator new[](unsigned) (vg_replace_malloc.c:197) ==13048== by 0x502E5DF: (within /usr/lib/qt3/lib/libqt-mt.so.3.2.3) ==13048== Final live pointer at 0xBEBD4350 allocated ==13048== at 0x401B974: operator new(unsigned) (vg_replace_malloc.c:164) ==13048== by 0x502F006: QString::QString(char const*) (in /usr/lib/qt3/lib/libqt-mt.so.3.2.3) ==13048== --13048-- o_cleanupMemBlock(0x622FCE88) --13048-- o_cleanupMemBlock mb=0x5F7CAB0 --13048-- cleanup shadow pointers --13048-- cleanup tracked pointers --13048-- killing range 0x8 bytes from 0x5F7CAB0 --13048-- killing range 0x8 bytes from 0x5F7CAB0 done. --13048-- killing range 0x4 bytes from 0xBEBD4350 done. --13048-- o_omegaDetector(0x18, 0x5F7CAB0) ## Value read from stack written into (sim)ESI . . . o_omegaDetecor shows address, value. Where address is very small, it is a register offset as used in PUT. On my 32 bit machine: 0x10 - (sim)ESP 0x18 - (sim)ESI o_omegaLoadTracker shows address, value. Nowhere is the value read from the stack at the top visible in the sim cpu until it is finally written into the sim ESI. That's what causes the false leak report - I have no visible references when the stack is invalidated, taking the final in-memory reference with it. If the stack invalidation happened after the load from the stack made it into the (sim) register, I would detect it and prevent the leak report. Tracking the SP for movement was only a hack attempt in order to try to get around the above problem. Hope this helps, Bryan "Brain Murders" Meredith On Saturday 12 Nov 2005 18:24, Julian Seward wrote: > > 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 > > > ------------------------------------------------------- > 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 > |
|
From: Julian S. <js...@ac...> - 2005-11-12 19:10:02
|
> Hope this helps, Not really. Like I said, show me some actual translations so I can see what you're getting at. J |
|
From: Bryan M. <om...@br...> - 2005-11-12 20:51:21
|
sorry - misunderstood. I'll try and sort that tomorrow. Brains On Saturday 12 Nov 2005 19:10, Julian Seward wrote: > > > Hope this helps, > > Not really. Like I said, show me some actual translations so I can see > what you're getting at. > > J > > > ------------------------------------------------------- > 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 > |
|
From: Bryan M. <om...@br...> - 2005-11-12 22:55:38
|
See below for the requested output. This is all it would produce for the section. What is the extents thing as I take you will need a lot more than this? Also, second alpha release available here: http://www.brainmurders.eclipse.co.uk/omega_ALPHA_02.patch.gz - maybe someone will look at the source code and see whats going on. Patch is against current svn. TODO: Fix this problem with false leaks occuring around stack invalidation. Some of the basic tests are now failing due to excessive hacking in order to solve the stack thing. Comments, patches and suggestions most welcome - knock yourselves out :D Bryan "Brain Murders" Meredith ==== BB 5133 QString::QString(char const*)+169(0x502EFF9) BBs exec'd 12335674 ==== ------------------------ Front end ------------------------ 0x502EFF9: movl $0x14, (%esp,,) ------ IMark(0x502EFF9, 7) ------ t0 = GET:I32(16) STle(t0) = 0x14:I32 0x502F000: movl %eax,%esi ------ IMark(0x502F000, 2) ------ PUT(60) = 0x502F000:I32 PUT(24) = GET:I32(0) 0x502F002: call 0x4C79524 ------ IMark(0x502F002, 5) ------ PUT(60) = 0x502F002:I32 t1 = Sub32(GET:I32(16),0x4:I32) PUT(16) = t1 STle(t1) = 0x502F007:I32 0x4C79524: jmp*l 0xAD28(%ebx) ------ IMark(0x4C79524, 6) ------ PUT(60) = 0x4C79524:I32 t3 = Add32(GET:I32(12),0xAD28:I32) t2 = LDle:I32(t3) goto {Boring} t2 can't show code due to extents > 1 |