From 81857b73737b6ac8432d2ae8eee6f75a5e2340c2 Mon Sep 17 00:00:00 2001 From: Eric Pouech Date: Mon, 18 Apr 2005 09:53:02 +0000 Subject: [PATCH] Minor cleanups. --- documentation/debugger.sgml | 108 ++++++++++++++++++------------------ 1 file changed, 54 insertions(+), 54 deletions(-) diff --git a/documentation/debugger.sgml b/documentation/debugger.sgml index 228b21675e0..5a22e7658a5 100644 --- a/documentation/debugger.sgml +++ b/documentation/debugger.sgml @@ -15,8 +15,7 @@ processes/threads from a Windows point of view. - Each Windows' thread is implemented as a Unix process (under - Linux using the clone syscall), meaning + Each Windows' thread is implemented as a Unix thread, meaning that all threads of a same Windows' process share the same (unix) address space. @@ -102,15 +101,16 @@ - Wine implements most of the Windows' debugging API (the - part in KERNEL32.DLL, not the one in - IMAGEHLP.DLL), and allows any program - (emulated or Winelib) using that API to debug a - W-process. - - - Wine also implements DBGHELP.DLL which - allows to look into symbols and types from any module (if + Wine implements most of the Windows' debugging API. The + first part of the debugging APIs (in + KERNEL32.DLL) allows a W-process, called + the debugger, to control the execution of another W-process, + the debuggee. To control means stopping/resuming execution, + enabling/disabling single stepping, setting breakpoints, + reading/writing debuggee memory... Another part of the + debugging APIs resides in DBGHELP.DLL + (and its ancestor IMAGEHLP.DLL) and lets + a debugger look into symbols and types from any module (if the module has been compiled with the proper options). @@ -138,7 +138,7 @@ winedbg telnet.exe -winedbg "hl.exe -windowed" +winedbg hl.exe -windowed @@ -201,7 +201,7 @@ winedbg "hl.exe -windowed" - continue: + continue the debugger had the ability to correct what's @@ -211,7 +211,7 @@ winedbg "hl.exe -windowed" - pass: + pass the debugger couldn't correct the cause of the @@ -462,7 +462,7 @@ winedbg "hl.exe -windowed" - Disassembling programs: + Disassembling programs You may also try to disassemble the offending program to @@ -538,7 +538,7 @@ call KERNEL.LSTRLEN - Sample debugging session: + Sample debugging session Let's debug the infamous Word SHARE.EXE @@ -821,7 +821,7 @@ Call KERNEL.96: FREELIBRARY(0x031f) ret=01cf:105c ds=01ff - Some basic debugger usages: + Some basic debugger usages After starting your program with @@ -968,7 +968,7 @@ wine -debug myprog.exe - Debugger: + Debugger this is the command line used to launch the debugger @@ -985,7 +985,7 @@ wine -debug myprog.exe - Auto: + Auto if this value is zero, a message box will ask the @@ -1041,7 +1041,7 @@ wine -debug myprog.exe per user basis. The key is (in my registry) -[eric\\Software\\Wine\\WineDbg] +[HKCU\\Software\\Wine\\WineDbg] Those options can be read/written while inside @@ -1897,7 +1897,7 @@ set $BreakAllThreadsStartup = 1 - info share; + info share lists all the dynamic libraries loaded in the debugged program (including .so files, NE and PE @@ -1907,7 +1907,7 @@ set $BreakAllThreadsStartup = 1 - info share <N>; + info share <N> @@ -1915,14 +1915,14 @@ set $BreakAllThreadsStartup = 1 - info regs; + info regs prints the value of the CPU registers - info segment <N>; + info segment <N> prints information on segment <N> (i386 @@ -1931,20 +1931,20 @@ set $BreakAllThreadsStartup = 1 - info segment; + info segment lists all allocated segments (i386 only) - info stack; + info stack prints the values on top of the stack - info map; + info map lists all virtual mappings used by the debugged program @@ -1952,7 +1952,7 @@ set $BreakAllThreadsStartup = 1 - info map <N> + info map <N> lists all virtual mappings used by the program of @@ -1961,7 +1961,7 @@ set $BreakAllThreadsStartup = 1 - info wnd <N> + info wnd <N> prints information of Window of handle <N> @@ -2221,13 +2221,31 @@ kdbg -r localhost:32878 wine - Even if latest gdb implements the - notion of threads, it won't work with Wine because the - thread abstraction used for implementing Windows' thread - is not 100% mapped onto the Linux POSIX threads - implementation. It means that you'll have to spawn a - different gdb session for each Windows' - thread you wish to debug. + If you plan to used gdb for a + multi-threaded Wine application (native or Winelib), then + gdb will be able to handle the multiple + threads directly only if: + + + + Wine is running on the pthread model (it won't work + in the kthread one). See the Wine architecture + documentation for further details. + + + + + gdb supports the multi-threading + (you need gdb at least 5.0 for that). + + + + In the unfortunate case (no direct thread support in + gdb because one of the above conditions + is false), you'll have to spawn a different + gdb session for each Windows' thread + you wish to debug (which means no synchronization for + debugging purposes between the various threads). @@ -2340,24 +2358,6 @@ $ gdb wine - - - Limitations - - - - - 16 bit processes are not supported (but calls to 16 bit - code in 32 bit applications are). - - - - - Function call in expression is no longer supported - - - -