https://wiki.eclipse.org/api.php?action=feedcontributions&user=Zulliger.indel.ch&feedformat=atomEclipsepedia - User contributions [en]2024-03-28T22:29:50ZUser contributionsMediaWiki 1.26.4https://wiki.eclipse.org/index.php?title=FAQ_How_do_I_use_the_platform_debug_tracing_facility%3F&diff=353193FAQ How do I use the platform debug tracing facility?2013-12-10T06:09:00Z<p>Zulliger.indel.ch: /* Turning on debug tracing */</p>
<hr />
<div>== Adding tracing to your code ==<br />
During development, it is common practice to print debugging messages to standard output. One common idiom for doing this is<br />
<source lang="java"><br />
private static final boolean DEBUG = true;<br />
...<br />
if (DEBUG)<br />
System.out.println("So far so good");<br />
</source><br />
<br />
The advantage of this approach is that you can flip the <tt>DEBUG</tt><br />
field to <tt>false</tt> when it comes time to deploy your code. The Java<br />
compiler will then remove the entire <tt>if</tt> block from the class file<br />
as flow analysis reveals that it is unreachable. The downside of this<br />
approach is that all the hard work that went into writing useful debug statements<br />
is lost in the deployed product. If your user calls up with a problem, you will have<br />
to send a new version of your libraries with the debug switches turned on<br />
before you can get useful feedback. Eclipse provides a tracing facility that is turned<br />
off by default but can be turned on in the field with a few simple steps.<br />
<br />
To instrument your code, use the methods <tt>Plugin.isDebugging</tt> and<br />
<tt>Platform.getDebugOption</tt> to add conditions to your trace statements:<br />
<source lang="java"><br />
private static final String DEBUG_ONE = <br />
"org.eclipse.faq.examples/debug/option1";<br />
...<br />
String debugOption = Platform.getDebugOption(DEBUG_ONE);<br />
if (ExamplesPlugin.getDefault().isDebugging() &&<br />
"true".equalsIgnoreCase(debugOption))<br />
System.out.println("Debug statement one.");<br />
</source><br />
<br />
This approach will also allow you to turn on tracing dynamically using the method<br />
<tt>Plugin.setDebugging</tt>. This can be very useful while debugging if you<br />
want to limit the amount of trace output that is seen. You simply start with tracing<br />
off and then turn it on when your program reaches a state at which tracing is useful.<br />
<br />
If you do not need dynamic trace enablement or if you are concerned about code<br />
clutter or performance, another tracing style yields cleaner and faster source:<br />
<source lang="java"><br />
private static final boolean DEBUG_TWO =<br />
ExamplesPlugin.getDefault().isDebugging() &&<br />
"true".equalsIgnoreCase(Platform.getDebugOption(<br />
"org.eclipse.faq.examples/debug/option2"));<br />
...<br />
if (DEBUG_TWO)<br />
System.out.println("Debug statement two.");<br />
</source><br />
<br />
This tracing style is not quite as good as the standard approach outlined at the beginning<br />
of this FAQ. Because the debug flag cannot be computed statically, the compiler will not be able to <br />
completely optimize out the tracing code. You will still be left with the extra code <br />
bulk, but the performance will be good enough for all but the most extreme applications.<br />
<br />
== Turning on debug tracing ==<br />
To turn tracing on, you need to create a trace-options file that contains a list<br />
of the debug options that you want to turn on. By default, the platform<br />
looks for a file called <tt>.options</tt> in the Eclipse install directory. This should<br />
be a text file in the Java properties file format, with one <tt>key=value</tt><br />
pair per line. To turn on the trace options in the preceding two examples, you <br />
need an options file that looks like this:<br />
<pre><br />
org.eclipse.faq.examples/debug=true<br />
org.eclipse.faq.examples/debug/option1=true<br />
org.eclipse.faq.examples/debug/option2=true<br />
</pre><br />
The first line sets the value of the flag returned by <tt>Plugin.isDebugging</tt>,<br />
and the next two lines define the debug option strings returned by the<br />
<tt>getDebugOption</tt> method on <tt>Platform</tt>.<br />
<br />
<i>Hint</i>: If you use tracing in your plug-in, you should keep in your <br />
plug-in install directory a <tt>.options</tt> file that contains <br />
a listing of all the possible trace options for your plug-in.<br />
This advertises your tracing facilities to prospective users and developers;<br />
in addition, the Run-time Workbench launch configuration will <br />
detect this file and use it to populate the Tracing Options <br />
page (Figure 6.1). If you browse through the plug-in directories of the <br />
Eclipse SDK, you will see that several plug-ins use this technique<br />
to document their trace options; for example, see <br />
<tt>org.eclipse.core.resources</tt> or <tt>org.eclipse.jdt.core</tt>.<br />
<br />
<i>Hint2</i>: If the trace levels don't show up in the according dialogs<br />
(Run/Debug configuration or in the workspace settings of the eclipse<br />
product) you may have forgotten to include the <tt>.options</tt> file <br />
in the <tt>Build Configuration</tt> (<tt>plugin.xml</tt>) of your plug-in.<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;<img src=../images/trace_options.png><br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;'''Figure 6.1'''&nbsp;&nbsp;<br />
Tracing Options page<br />
<br />
Finally, you need to enable the tracing mechanism by starting Eclipse with the <br />
<tt>-debug</tt> command line argument. You can, optionally,<br />
specify the location of the debug options file as either a URL or a file-system path<br />
after the <tt>-debug</tt> argument.<br />
<br />
<hr><font size=-2>This FAQ was originally published in [http://www.eclipsefaq.org Official Eclipse 3.0 FAQs]. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the [http://www.eclipse.org/legal/epl-v10.html Eclipse Public License v1.0].</font></div>Zulliger.indel.chhttps://wiki.eclipse.org/index.php?title=CDT/cdt-debug-dsf-gdb-extensibility&diff=262065CDT/cdt-debug-dsf-gdb-extensibility2011-07-21T06:42:23Z<p>Zulliger.indel.ch: /* How to extend DSF-GDB: Extended by mentioning some example class names and mention the need of extending the extension point */</p>
<hr />
<div>= How to extend DSF-GDB =<br />
<br />
Thanks to DSF, DSF-GDB can easily be extended by replacing/adding/removing different services. To do this one can create a custom service factory by:<br />
<br />
# sub-class the DSF-GDB service you want to modify (such as GDBProcesses_7_2, GDBRunControl_7_2_NS), or create your entirely new version (by subclassing AbstractDsfService).<br />
# sub-class org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate and override GdbLaunchDelegate#newServiceFactory().<br />
# sub-class the appropriate service factory such as org.eclipse.cdt.dsf.gdb.service.GdbDebugServicesFactory or org.eclipse.cdt.dsf.gdb.service.GdbDebugServicesFactoryNS (for GDB non-stop debugging) and override any services' creation method to instantiate your own version of the service. Other versions of GDB can also be handled in those services' creation methods.<br />
# Finally, make sure your customized "GDB launch delegate" class gets instantiated by extending the org.eclipse.debug.core.launchDelegates extension point.<br />
<br />
In some cases where small changes are required to MI commands, overriding the entire service may be unnecessary. Instead, one can extend DSF-GDB's command factory. To do this, one still requires a new services factory, but only to be able to specify the new command factory:<br />
<br />
# sub-class any MI command class and its output class to add your changes. These are found in org.eclipse.cdt.dsf.mi.service.command.commands and org.eclipse.cdt.dsf.mi.service.command.output<br />
# sub-class org.eclipse.cdt.dsf.mi.service.command.CommandFactory and override/add your necessary changes.<br />
# sub-class org.eclipse.cdt.dsf.gdb.launching.GdbLaunchDelegate and override GdbLaunchDelegate#newServiceFactory().<br />
# sub-class org.eclipse.cdt.dsf.gdb.service.GdbDebugServicesFactory and override GdbDebugServicesFactory#createCommandControl() to pass in your own command factory.<br />
<br />
Once you have the above framework in place, overriding other DSF-GDB services/commands becomes extremely quick.<br />
<br />
== Requested improvements ==<br />
<br />
This section lists the different use cases that the community would like to see addressed to allow for easier extensibility of DSF-GDB.<br />
<br />
* Allow FinalLaunchSequence to be easily overridden (completed in [http://bugs.eclipse.org/321084 bug 321084])<br />
* Allow to easily add a new service (completed in [http://bugs.eclipse.org/326951 bug 326951] and [http://bugs.eclipse.org/338769 bug 338769])<br />
* Allow to override the use of -exec-run vs -exec-continue at startup (completed in [http://bugs.eclipse.org/319257 bug 319257])</div>Zulliger.indel.ch