Dynamically adding debug channels (__wine_dbg_set_channel_flags)

[Daniel Santos]

What I'm proposing shouldn't interfere with that.  However, my original proposal is lacking (as I discovered when trying it out) because most of the object files that use debug logging end up with a static struct  __wine_debug_channel variable that can't be changed from libwine after initialization.

I think I just need to create a working solution and propose it as a patch.  Performance is a pretty huge issue where, especially when running with WINEDEBUG=+all, so whatever I come up with will have to be very performance sensitive.  Either way, the idea is to provide a mechanism for dynamically changing debug channels.  Since this isn't something that many people should need (and especially not end users) this should be disabled by default.

--- On Fri, 5/8/09, André Hentschel <nerv at dawncrow.de> wrote:

From: André Hentschel <nerv at dawncrow.de>
Subject: Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)
To: daniel.santos at pobox.com, wine-devel at winehq.org
Date: Friday, May 8, 2009, 7:07 AM

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
> 
> 
> ------------------------------------------------------------------------
> 
> 
>   




      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20090509/2554236e/attachment.htm>