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