Debugging Wine thoughts

[Boaz Harrosh]

celticht32 at aol.com wrote:
> Dan / All,
> I think what the guy was asking on improving winedbg is to have some
> sort of visual debugger much like VC/C++ , Eclipse,
> Borland C++ or the like... Where you can step through the code (seeing
> the whole thing like any visual debugger). 
> Then when looking at stacks you  click on a variable or stack and it
> either winds it back or display's it. 
> 
> Below is my thoughts on what would be a nice to have in some form of
> Debugger / Gui Debugger for Wine
> 
> So my wish list would be:
> 1) Some form of a Standard Gui Debugger
> 2) A way to select  the debug flags used with an explanation of what
> each is for... +sed is for this +relay does that...etc....  
> 3) When you do +relay you could open separate output windows for each
> thread
> 4) The ability to turn each of the +relay wine thread output on or off...
> 4) Currently Wading through a relay log is a real pain and in some cases
> it prevents the problem from occuring.
>     Time outs because of too much data being collected and then having
> to wade through and determine what to and not to turn off.
>     So a note or best practice somewhere showing the heavy hitters in a
> +relay log  and turn them off by default.  However, note
>     somewhere saying  if +relay doesnt give enough information then turn
> on just these flags and run. That way we are not managing
>     flag lists when trying to figure out whats going wrong in an
> application. IMHO +relay is too unweldly and turning each flag on
>     individually is as well, so there needs to be some sort of happy
> medium somewhere.
> 5) A window with a list of the important wine structures or resources
> that can be watched as the application runs.
> 6) Source code debugging in the GUI with step through, break points,
> etc..( not like now in winedbg but more like one of the GUI's mentioned
> before)
> 7) Loading of application from gui debugger and run it
> 8) Ability to look at a stack and backtrace in the GUI
> 9) Value Watches within the GUI.
> 10) Code Checking
>       Some sort of bounds checking...
>       Uninitialized variable checking....
>       Unreachable Code Checking
> 11) Use the GUI to help enforce the Wine Coding standard.. most modern
> GUI environments let you specify a style of coding.
> This would help the new people understand and follow the coding
> standards set up... instead of guessing like they do now.
> 12) Online help / Context help...  point to the IC in the wiki... lots
> of good stuff there... just hard to find sometimes....
> 13) Integration with bugzilla... they find a bug... they create it in
> the GUI.. dump out the screen, stack and the like... so some
> of the base information is collected instead of wasting time back and
> forth and having so many invalid bugs. Again this format
> can be enforced through coding style templates... you want to submit a
> bug here is what you do... check boxes to include things...
> like I said screen shots... logs, traces, variables, hardware config, etc...
> 14) Integration with GIT... check and see if there is a new tree out
> there.. if so... flag it and git it...
> 15) Link to whats fixed in the new GIT tree... or a list of it...
> 16) Link to Dan's patchwatcher status... (kinda a workflow sort of
> thing) to know whats good and bad...
> 17) Generation of the GIT patch and then mail it to the list through a
> button...
> 18) GIT integration
> 
> You have to remember guy's alot of the new people coming in are not old
> timers like some of us who grew up in a non-gui
> world.. Like it or not  they are used to doing things in certain ways
> and I think we could get alot more people looking at
> bugs and helping fix them if we started thinking of something along
> these lines. This of course is not a complete list...
> And I am sure this is going to start a flame war or something close to
> it.. But I think this might be a good next step for something
> like the summer of code people to do.. or whomever maintains the wine
> debugger to think seriously about.
> 
> Most of these things I think could be implemented using the current wine
> debugger with some form of pipe between it and the GUI.
> That way the 'purists' can still debug using winedebug like now and the
> new people who choose to can use the GUI?
> 
> Thoughts????????????????????????????????
> 
> 

I had grate success in the past with debugging windows programs using
the --gdb mode under Kdevelop . Quote: "WineDbg can act as a remote 
monitor for GDB" this is done with the --gdb switch.
Read documentation about how to do this. Since --gdb gives you a remote
gdb target, then a full screen debugger based on gdb like Kdevelop feels
right at home. And you can see/debug both your Windows as well as wine 
source code. Also code that you have compiled with msvc++.

The only problem is that you do not have all the windowism
goodies winedbg gives you. I have once tried to hack CodeBlocks, to spawn
winedbg instead of gdb. But they are painfully not "output" compatible.
Painfully I mean that they are very close, but different enough to break
the gdb-output parsers. The easiest way would be to fix winedbg and submit
patches but I never got to that.

You might also get lucky with mingw based gui-debuggers. But you will not
be able to debug msvc++ compiled code. Just like on windows.

> Problems I have noticed when debugging...
> If I kill (press the X button or close it from the task bar) the wine
> application, Wine does not clean up from itself... it leaves the
> wine mount daemon running. so I have to kill all the wine processes
> before I can restart wine. Otherwise any windows
> application which loads another application fails to start IE a game
> with a loader which then starts the game (I have found this
> in alot of MMO's where you have some form of login screen / loader which
> then loads in the actual game) (and no you cant
> always just call the main exe)
> 
> Question :
> Why does wine have to allocate all its memory at startup? re... the
> issue that is causing the ATI drivers to have such
> a fuss....  why not just allocate as needed? or have the ability (if its
> not there already) to specify the total amount of memory
> which is available to the wine process and limit wine to just that
> ammount of memory (kind of like the way most VM machines
> have the option of setting the maximum amount of memory which is available).
> 

Free Life
Boaz