Dynamically adding debug channels (__wine_dbg_set_channel_flags)

André Hentschel nerv at dawncrow.de
Fri May 8 07:07:18 CDT 2009


The Problem with a pre-processor setting would be that the endusers may 
not be able to make good logs for the devs.
At the moment you can say to a user "send a log using 
'WINEDEBUG=commctrl wine program.exe'", the user doesnt have to know 
what he is doing exactly, but he sends a usefull text. That wouldnt be 
possible anymore as i understand it.

Best regards André Hentschel

Daniel Santos schrieb:
> It would seem quite helpful for debugging odd situations to be able to 
> turn debugging on and off programmatically.  I like not having every 
> debug class loaded in memory by default (and everything that goes with 
> maintaining that global list), but it would seem quite helpful for 
> troubleshooting, testing and debugging special cases (mostly where one 
> doesn't have the sources of the troublesome app).
>
> Thus, perhaps __wine_dbg_set_channel_flags could add the debug channel 
> to debug_options if it doesn't exist and even allow setting the 
> default_flags (say by having a zero-length name in the channel 
> argument) or even another function which would allow it.  I'm not sure 
> what thread synchronization implications this would bring about (and 
> the associated costs of the sync objects), it seems it would require 
> at the least the use of a critical section to modify the 
> debug_options, but perhaps this can be a pre-processor driven option?  
> The configure could have a --enable-dynamic-channels or some such that 
> would set a pre-processor macro, etc.
>
> Alternatively, a cheaper (hackier) mechanism of thread-safety could be 
> achived by having the debug_options be contained in a struct along 
> with the nb_debug_options and have them heap-allocated so that the 
> debug_options pointer could be changed in a single machine 
> instruction.  A similar mechanism (i.e., hack) could be use to free 
> the old debug_options struct.  That's ugly, but I'm just presenting 
> options.
>
> Daniel
>
>
> ------------------------------------------------------------------------
>
>
>   




More information about the wine-devel mailing list