reuben at ugcs.caltech.edu
Mon Oct 18 04:03:23 CDT 2004
Thanks. I think that "watch" ought to do something like what I wanted,
but it doesn't seem to work: no matter what watch point I ask for, winedbg
always says it's at the same address, and I don't actually get a break
when that address gets changed.
Watchpoint 1 at 0x405ae8c4
Have I misunderstood what a watchpoint does? I expected that "watch
*0x0041a5e0" would set something like a breakpoint, pulling up a debugger
prompt whenever anything got written to memory location 0x0041a5e0.
I think I have found the other bug that stops this app from working, but
as you said that should go to the devel list.
On Sun, 17 Oct 2004, Rein Klazes wrote:
> On Sat, 16 Oct 2004 15:25:23 -0700 (PDT), you wrote:
> > Hi folks,
> > I am trying to debug a scientific / engineering application called SRIM
> > (www.srim.org, particularly the batch-mode version of SRIM 2003 called
> > "SRModule"). This is my first experience with a debugger like winedbg, so
> > I am still learning how best to use it.
> > My question for now is: given a known breakpoint, and a value to watch (in
> > this case $ecx), is there an easy way to find the last instruction before
> > the breakpoint that changed this value? The only way I know of to do this
> > so far is to set an earlier breakpoint and spend a whole lot of time stepping
> > through instructions.
> Not that I know of. You can disassemble the code before the breakpoint,
> but if the code include jumps it takes a lot of interpretations.
> (you are talking about stepping through the applications code I assume.
> Wines code is easier because you have the source)
> > Depending on how the debugging goes, I'll probably ask some more specific
> > questions about the exceptions I'm seeing. The first problem was pretty
> > straightforward, and is successfully fixed, so that's an encouraging
> > start!
> I think you should ask these questions on the developer list.
> Rein Klazes
> rklazes at xs4all.nl
More information about the wine-users