1 <chapter id=
"debugging">
2 <title>Debug Logging
</title>
5 To better manage the large volume of debugging messages that
6 Wine can generate, we divide the messages on a component basis,
7 and classify them based on the severity of the reported problem.
8 Therefore a message belongs to a
<emphasis>channel
</emphasis>
9 and a
<emphasis>class
</emphasis> respectively.
12 This section will describe the debugging classes, how you can
13 create a new debugging channel, what the debugging API is,
14 and how you can control the debugging output. A picture is
15 worth a thousand words, so here are a few examples of the
16 debugging API in action:
18 ERR(
"lock_count == 0 ... please report\n");
19 FIXME(
"Unsupported RTL style!\n");
20 WARN(
": file seems to be truncated!\n");
21 TRACE(
"[%p]: new horz extent = %d\n", hwnd, extent );
22 MESSAGE(
"Could not create graphics driver '%s'\n", buffer );
26 <sect1 id=
"dbg-classes">
27 <title>Debugging classes
</title>
30 A debugging class categorizes a message based on the severity
31 of the reported problem. There is a fixed set of classes, and
32 you must carefully choose the appropriate one for your messages.
33 There are five classes of messages:
37 <term><literal>FIXME
</literal></term>
40 Messages in this class are meant to signal unimplemented
41 features, known bugs, etc. They serve as a constant and
42 active reminder of what needs to be done.
47 <term><literal>ERR
</literal></term>
50 Messages in this class indicate serious errors in
51 Wine, such as as conditions that should never happen
57 <term><literal>WARN
</literal></term>
60 These are warning messages. You should report a
61 warning when something unwanted happens, and the
62 function can not deal with the condition. This
63 is seldomly used since proper functions can usually
64 report failures back to the caller. Think twice before
65 making the message a warning.
70 <term><literal>TRACE
</literal></term>
73 These are detailed debugging messages that are mainly
74 useful to debug a component. These are turned off unless
80 <term><literal>MESSAGE
</literal></term>
83 There messages are intended for the end user. They do not
84 belong to any channel. As with warnings, you will seldomly
85 need to output such messages.
92 <sect1 id=
"dbg-channels">
93 <title>Debugging channels
</title>
96 Each component is assigned a debugging channel. The
97 identifier of the channel must be a valid C identifier
98 (reserved word like
<type>int
</type> or
<type>static
</type>
99 are premitted). To use a new channel, simply use it in
100 your code. It will be picked up automatically by the build process.
104 Typically, a file contains code pertaining to only one component,
105 and as such, there is only one channel to output to. You can declare
106 a default chanel for the file using the
107 <symbol>WINE_DEFAULT_DEBUG_CHANNEL()
</symbol> macro:
109 #include
"wine/debug.h"
111 WINE_DEFAULT_DEBUG_CHANNEL(xxx);
114 FIXME(
"some unimplemented feature", ...);
117 ERR(
"This should never be non-null: %d", zero);
122 In rare situations there is a need to output to more than one
123 debug channel per file. In such cases, you need to declare
124 all the additional channels at the top of the file, and
125 use the _-version of the debugging macros:
127 #include
"wine/debug.h"
129 WINE_DEFAULT_DEBUG_CHANNEL(xxx);
130 WINE_DECLARE_DEBUG_CHANNEL(yyy);
131 WINE_DECLARE_DEBUG_CHANNEL(zzz);
134 FIXME(
"this one goes to xxx channel");
136 FIXME_(yyy)(
"Some other msg for the yyy channel");
138 WARN_(zzz)(
"And yet another msg on another channel!");
145 <sect1 id=
"dbg-checking">
146 <title>Are we debugging?
</title>
149 To test whether the debugging channel
<literal>xxx
</literal> is
150 enabled, use the
<symbol>TRACE_ON
</symbol>,
<symbol>WARN_ON
</symbol>,
151 <symbol>FIXME_ON
</symbol>, or
<symbol>ERR_ON
</symbol> macros. For
158 You should normally need to test only if
<literal>TRACE_ON
</literal>,
159 all the others are very seldomly used. With careful coding, you
160 can avoid the use of these macros, which is generally desired.
164 <sect1 id=
"dbg-helpers">
165 <title>Helper functions
</title>
168 Resource identifiers can be either strings or numbers. To
169 make life a bit easier for outputting these beasts (and to
170 help you avoid the need to build the message in memory), I
171 introduced a new function called
<function>debugres
</function>.
174 The function is defined in
<filename>wine/debug.h
</filename>
175 and has the following prototype:
178 LPSTR debugres(const void *id);
181 It takes a pointer to the resource id and returns a nicely
182 formatted string of the identifier (which can be a string or
183 a number, depending on the value of the high word).
184 Numbers are formatted as such:
196 Simply use it in your code like this:
199 #include
"wine/debug.h"
203 TRACE(
"resource is %s", debugres(myresource));
207 Many times strings need to be massaged before output:
208 they may be
<literal>NULL
</literal>, contain control
209 characters, or they may be too long. Similarly, Unicode
210 strings need to be converted to ASCII for usage with
211 the debugging API. For all this, you can use the
212 <function>debugstr_[aw]n?
</function> familly of functions:
214 HANDLE32 WINAPI YourFunc(LPCSTR s)
216 FIXME(
"(%s): stub\n", debugstr_a(s));
223 <sect1 id=
"dbg-control">
224 <title>Controlling the debugging output
</title>
227 It is possible to turn on and off debugging output from
228 within the debugger using the set command. Please see the
229 WineDbg Command Reference section for how to do this.
233 The
<parameter>--debugmsg
</parameter> command line
234 option controls the output of the debug messages.
235 It has the following syntax:
236 <parameter>--debugmsg [yyy]#xxx[,[yyy1]#xxx1]*
</parameter>
242 <literal>#
</literal> is either
<literal>+
</literal> or
248 when the optional class argument (
<literal>yyy
</literal>)
249 is not present, then the statement will
250 enable(
<literal>+
</literal>)/disable(
<literal>-
</literal>)
251 all messages for the given channel (
<literal>xxx
</literal>)
252 on all classes. For example:
255 --debugmsg +reg,-file
258 enables all messages on the
<literal>reg
</literal>
259 channel and disables all messages on the
260 <literal>file
</literal> channel.
265 when the optional class argument (
<literal>yyy
</literal>)
266 is present, then the statement will enable
267 (
<literal>+
</literal>)/disable(
<literal>-
</literal>)
268 messages for the given channel (
<literal>xxx
</literal>)
269 only on the given class. For example:
272 --debugmsg trace+reg,warn-file
275 enables trace messages on the
<literal>reg
</literal>
276 channel and disables warning messages on the
277 <literal>file
</literal> channel.
282 also, the pseudo-channel all is also supported and it
283 has the intuitive semantics:
286 --debugmsg +all -- enables all debug messages
287 --debugmsg -all -- disables all debug messages
288 --debugmsg yyy+all -- enables debug messages for class yyy on all
290 --debugmsg yyy-all -- disables debug messages for class yyy on all
297 --debugmsg warn-all -- disables all warning messages.
303 Also, note that at the moment:
308 the
<literal>FIXME
</literal> and
<literal>ERR
</literal>
309 classes are enabled by default
314 the
<literal>TRACE
</literal> and
<literal>WARN
</literal>
315 classes are disabled by default
321 <sect1 id=
"dbg-compiling">
322 <title>Compiling Out Debugging Messages
</title>
325 To compile out the debugging messages, provide
326 <command>configure
</command> with the following options:
329 --disable-debug -- turns off TRACE, WARN, and FIXME (and DUMP).
330 --disable-trace -- turns off TRACE only.
333 This will result in an executable that, when stripped, is
334 about
15%-
20% smaller. Note, however, that you will not be
335 able to effectively debug Wine without these messages.
338 This feature has not been extensively tested--it may subtly
343 <sect1 id=
"dbg-notes">
344 <title>A Few Notes on Style
</title>
347 This new scheme makes certain things more consistent but
348 there is still room for improvement by using a common style
349 of debug messages. Before I continue, let me note that the
350 output format is the following:
353 yyy:xxx:fff
<message
>
356 yyy = the class (fixme, err, warn, trace)
357 xxx = the channel (atom, win, font, etc)
358 fff = the function name
361 these fields are output automatically. All you have to
362 provide is the
<message
> part.
365 So here are some ideas:
371 do not include the name of the function: it is included automatically
376 if you want to output the parameters of the function, do
377 it as the first thing and include them in parentheses,
380 TRACE(
"(%d, %p, ...)\n", par1, par2, ...);
386 for stubs, you should output a
<literal>FIXME
</literal>
387 message. I suggest this style:
389 FIXME(
"(%x, %d, ...): stub\n", par1, par2, ...);
395 try to output one line per message. That is, the format
396 string should contain only one
<literal>\n
</literal> and it
397 should always appear at the end of the string. (there are
398 many reasons for this requirement, one of them is that
399 each debug macro adds things to the beginning of the line)
404 if you want to name a parameter, use
<literal>=
</literal> :
406 FIXME(
"(fd=%d, file=%s): stub\n", fd, name);
415 <!-- Keep this comment at the end of the file
418 sgml-parent-document:("wine-devel.sgml" "set" "book" "part" "chapter" "")