I have the debugger starting in its own xterm (or rxvt,...)
there are (at least) two issues that need to be fixed:
A] the command line for starting the debugger is read from the registry (something
like "xterm -T WineDebugger -e winedbg <pid> <hEvent>)
(read msdn.microsoft.com/library/periodic/period97/pietrek.htm for the details)
then CreateProcess is called upon this command line. the only issue are that
if xterm (/usr/X11R6/bin/xterm) location is not mapped on a Windows drive letter,
this won't work (and not calling CreateProcess, but UNIX_CreateProcess is not
correct either => one may want to set up a native windows debugger)
B] currently, the debugger uses the argv0 variable to get the unix filename
of the debugged process, to map its content in the debugger's address space
and read the debugging information. with ASS in place, this no longer works
(especially when debugger is started with the form winedbg <pid> <hEvent>
for A], I don't have any good proposals (except make sure that xterm, or
whatever is needed, has been correctly set up in wine.conf (ie is accessible
from a Windows path). Any better idea ?
for B], two proposals:
1/ since the debugger can be invoked in two forms (winedbg <exec_name> or
winedbg <pid> <hEvent>), it's easy to grab exec name from the first form.
the registry entry can be extended to get an extra parameter which can
be expanded into the filename
xterm -T WineDebugger -e winedbg -uname "@U" <pid> <hEvent>
this shall be the unix name of the exec (so far, there's no requirement
for wine to be mapped to a windows drive in wine.conf)
2/ instead of grabbing the list of .so files from the _DYNAMIC symbol
(and mmaping each one of them to read debugging info - stabs -), we could
also patch the builtin PE loader so that the stabs debugging sections
(.stabs, .stabstr, .dynsym and .symtab) are added to the list of the
sections in the PE header (mingw compiler uses a similar technique).
if a .so contains several PE headers, stabs shall be only loaded once,
even if several PE modules from this .so are loaded (I'd suggest having
all PE headers having the stabs sections and the debugger checking
for already loaded stab section because there's no way to know which
PE module(s) shall be loaded from a .so)
the option 2) will not allow to grab symbols from the wine exec (since
there is no known PE module for it - but that's not a big deal IMO -)
(if it were, we could define a dummy PE module in wine exec, which is loaded
at startup by KERNEL32, and this this should do the trick)
options 1 and 2 should work fine for both wine exec and any winelib program
this should also be ok when no dynamic linking is in place
even if option 2 requires more work, it seems to me the cleanest of the two
any comment is welcome
For Alexandre, I also found some (primary) documentation on 16 bit module
support for NT debugger
(msdn.microsoft.com/library/periodic/period98/hood0898.htm), but I'm not
100% sure the VDM model matches Wine's implementation of 16 bit tasks
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
