Hi,
Winedbg's watchpoints don't seem to work for me: when I try to watch a memory location, winedbg responds that a watchpoint has been set at a different, always constant location (I suspect this is actually in winedbg's memory space). Nothing happens when the location I was trying to watch changes.
Here is a cut-and-paste from my winedbg session. I try to watch memory location 0x0041a5ec, but I can set other breakpoints and see that the value has changed without the watchpoint taking effect.
----------------------------------------------------------------------- Wine-dbg>run In 32 bit mode. 0x4049a81f start_process+0xcf [/home/reuben/project/wine/wine/dlls/kernel/../../include/winternl.h:1249] in kernel32: jmp 0x4049a815 start_process+0xc5 [/home/reuben/project/wine/wine/dlls/kernel/process.c:1022] in kernel32 1249 static inline void WINAPI DbgBreakPoint(void) { __asm__ __volatile__("int3"); } 1249 static inline void WINAPI DbgBreakPoint(void) { __asm__ __volatile__("int3"); } Wine-dbg>watch *0x0041a5ec Watchpoint 1 at 0x405ae8c4 Wine-dbg>x 0x0041a5ec 00000000 Wine-dbg>break *0x004130ec Breakpoint 2 at 0x004130ec Wine-dbg>cont fixme:ole:CoRegisterMessageFilter stub Stopped on breakpoint 2 at 0x004130ec Wine-dbg>x 0x0041a5ec 403e9d40 Wine-dbg>cond 2 $ecx==0x10 Wine-dbg>cont Stopped on breakpoint 2 at 0x004130ec Wine-dbg>x 0x0041a5ec 00000000 Wine-dbg>info break Breakpoints: 2: y 0x004130ec (1) stop when ($ecx == 16) Watchpoints: 1: y 0x405ae8c4 on 4 bytes (W) --------------------------------------------------------------------------
The fact that winedbg thinks the watchpoint is 0x405ae8c4 is especially puzzling, but it's entirely possible that the confusion lies with me rather than winedbg.
Thanks, Walter
Walt Ogburn a écrit :
Hi,
Winedbg's watchpoints don't seem to work for me: when I try to watch a memory location, winedbg responds that a watchpoint has been set at a different, always constant location (I suspect this is actually in winedbg's memory space). Nothing happens when the location I was trying to watch changes.
does the attached patch help ? A+
Hi Eric,
Thanks. That fixes the watchpoints, but introduces a couple of small problems:
1) in dbg.y, break_add_watch_from_lvalue should take only one argument (drop second argument)
2) in dbg.y, I have no minidump_write. Should this be replaced with dbg_printf("%s\n", $2); ?
After fixing these two things, breakpoints work, although the instruction pointer displayed is the one just after the watched address gets written to. Perhaps this is the expected behavior, but it would be nice to have the instruction that makes the write instead.
- Walter
On Wed, 20 Oct 2004, Eric Pouech wrote:
Walt Ogburn a �crit :
Hi,
Winedbg's watchpoints don't seem to work for me: when I try to watch a memory location, winedbg responds that a watchpoint has been set at a different, always constant location (I suspect this is actually in winedbg's memory space). Nothing happens when the location I was trying to watch changes.
does the attached patch help ? A+
Walt Ogburn a �crit :
Hi Eric,
Thanks. That fixes the watchpoints, but introduces a couple of small problems:
- in dbg.y, break_add_watch_from_lvalue should take only one argument
(drop second argument)
that shouldn't be that way (your fix is correct)
- in dbg.y, I have no minidump_write. Should this be replaced with dbg_printf("%s\n", $2); ?
no, that some unapplied work (completly unrelated to the patch)
After fixing these two things, breakpoints work, although the instruction pointer displayed is the one just after the watched address gets written to. Perhaps this is the expected behavior, but it would be nice to have the instruction that makes the write instead.
no, we should point to the correct insn, I'll look into it. A+
Eric Pouech a �crit :
Walt Ogburn a ?crit :
Hi Eric,
Thanks. That fixes the watchpoints, but introduces a couple of small problems:
- in dbg.y, break_add_watch_from_lvalue should take only one argument
(drop second argument)
that shouldn't be that way (your fix is correct)
- in dbg.y, I have no minidump_write. Should this be replaced with dbg_printf("%s\n", $2); ?
no, that some unapplied work (completly unrelated to the patch)
After fixing these two things, breakpoints work, although the instruction pointer displayed is the one just after the watched address gets written to. Perhaps this is the expected behavior, but it would be nice to have the instruction that makes the write instead.
no, we should point to the correct insn, I'll look into it.
in fact, it'll be hard to change it. ia-32 reports insn after the one that triggers the watch. The rationale beeing that you must execute the insn in order to now of the write change (unlike a seg fault where you cannot know execute the insn). GDB behaves the same (it shows the line after the one that triggered the watch).
Hi Eric,
I suspected that might be the case. It just takes a little bit of guessing to find the previous expression, since its size is not fixed.
Thanks, Walter
no, we should point to the correct insn, I'll look into it.
in fact, it'll be hard to change it. ia-32 reports insn after the one that triggers the watch. The rationale beeing that you must execute the insn in order to now of the write change (unlike a seg fault where you cannot know execute the insn). GDB behaves the same (it shows the line after the one that triggered the watch).
-
Eric Pouech -
Walt Ogburn