http://bugs.winehq.org/show_bug.cgi?id=24676
--- Comment #2 from Andrew andrew.pub@sophistasis.com 2010-10-09 16:05:04 CDT --- (In reply to comment #1)
I can't reproduce what you describe. Wine-dbg>break mscenccomm!MSC_USBConnect fixme:dbghelp_dwarf:compute_location Only supporting one breg (18 -> 24) Many symbols with name 'mscenccomm!MSC_USBConnect', choose the one you want (<cr> to abort): [1]: 0x100011e0 MSC_USBConnect in mscenccomm [2]: 0x100011e0 MSC_USBConnect in mscenccomm => 1 Breakpoint 1 at 0x100011e0 MSC_USBConnect in mscenccomm Wine-dbg>c Stopped on breakpoint 1 at 0x100011e0 MSC_USBConnect in mscenccomm Wine-dbg>stepi 17 0x10001a3f: call *%esi Wine-dbg>nexti 10 0x10001a5d: movl %eax,%ebp
which works flawlessly afterwards. Are you sure you haven't set other breakpoints (on addresses which are not instructions boundaries? => this could explain why you get different instructions at the end) btw, try also hardware breakpoints, they don't have the defaults of modifying instructions code.
No, there are no other breakpoints. I just tested it using the --gdb setting, and it works fine as a remote interface (no bug)... (though a separate bug popped up, which I wont go into for it isn't repeatable/complete)
Oddly, your dis-assembly stopped at 0x10001a5d -- whereas mine stops at 0x10001a5e for the exact same command sequence using pure winedbg without --gdb.
so,... I just backed up -- and re deleted my wine registry (.wine) and made it rebuild all defaults (again) to see what would happen from scratch, and now I get the same dis-assembly as you which is not a call instruction using pure wine-dbg. Hmm... That suggests that adding a USB drive name to the registry causes wine-dbg to disassemble instructions differently than gdb. I'll post again when I have isolated the cause(s) required to crash the debugger.