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 <[email protected]> wrote: From: André Hentschel <[email protected]> Subject: Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags) To: [email protected], [email protected] 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 > > > ------------------------------------------------------------------------ > > >
