Re: Tip: use of GDB with Java/gcj (and ant)
Daniel Risacher writes:
>
> I recently started developing with gcj on debian and wanted to use
> gdb for debugging, but I've struggled a bit with it. I had actually
> composed a lengthy set of questions to ask here on the list, but in
> writing the email, I stumbled across the answer, which I now present.
>
> The problem: I wasn't getting any debugging information (line numbers
> or local symbols into the code when I compiled with ant. My javac
> task in build.xml looked like this:
>
> <javac debug="true" verbose="yes" debuglevel="source" includeJavaRuntime="no"
> compiler="gcj" destdir="classes">
> <src path="src" />
> <include name="**/*.java" />
> <compilerarg line=" --main=Main -o Coast" />
> </javac>
>
> The solution was to change the javac task to this:
>
> <javac verbose="yes" includeJavaRuntime="no"
> compiler="gcj" destdir="classes">
> <src path="src" />
> <include name="**/*.java" />
> <compilerarg line="-g --main=Main -o Coast" />
> </javac>
>
> Note that the 'debug' and 'debuglevel' properties were removed, and
> the '-g' option was added to 'compilerarg'
>
> I hope this helps someone else avoid the hand-wringing and
> teeth-gnashing I went through.
I've come across a few RPMS with missing debuginfo and wasted a great
deal of time trying to rebuild to get the debuginfo.
The problem seems to be that some ant scripts force debugging to be
off or perhaps inherited from a property that no-one remembered to
set. This is compounded by the fact that some ant scripts unzip source
archives and then call ant recursively to build them: in such a case
it's very hard to patch build.xml to force debugging=true.
This patch for ecj forces debuginfo always to be generated while
rebuilding an RPM, no matter what ant thinks. I realize it's
something of a kludge, but it's better than the current situation.
When compiling C/C++/etc, RPM passes "-g" in RPM_OPT_FLAGS. An
alternative to this patch might be to scan RPM_OPT_FLAGS for "-g" and
only turn on debugging if it's present. However, I doubt that in
practice it'd make any difference.
Something similar would work for Debian. I know of no circumstances
in which we ever wish to ship packages that don't have debuginfo.
Andrew.
--- eclipse-3.1.1/plugins/org.eclipse.jdt.core/batch/org/eclipse/jdt/internal/compiler/batch/Main.java.orig 2006-01-19 17:53:49.000000000 +0000
+++ eclipse-3.1.1/plugins/org.eclipse.jdt.core/batch/org/eclipse/jdt/internal/compiler/batch/Main.java 2006-01-19 18:06:32.000000000 +0000
@@ -2405,6 +2405,29 @@
this.times = new long[this.repetitions];
this.timesCounter = 0;
}
+
+ {
+ // If we're building an RPM, force full debugging info to
+ // be generated, no matter what options have been passed
+ // by Ant. This is something of a kludge, but it is far
+ // better than the alternative, which is having class
+ // files with debug info mysteriously missing.
+
+ String RpmPackageName = System.getenv("RPM_PACKAGE_NAME");
+ String RpmArch = System.getenv("RPM_ARCH");
+ String RpmBuildRoot = System.getenv("RPM_BUILD_ROOT");
+ if (RpmPackageName != null && RpmArch != null && RpmBuildRoot != null) {
+ this.options.put(
+ CompilerOptions.OPTION_LocalVariableAttribute,
+ CompilerOptions.GENERATE);
+ this.options.put(
+ CompilerOptions.OPTION_LineNumberAttribute,
+ CompilerOptions.GENERATE);
+ this.options.put(
+ CompilerOptions.OPTION_SourceFileAttribute,
+ CompilerOptions.GENERATE);
+ }
+ }
}
private void addNewEntry(final int InsideClasspath, final int InsideSourcepath, ArrayList bootclasspaths, ArrayList classpaths,ArrayList sourcepathClasspaths, String currentClasspathName, ArrayList currentRuleSpecs, int mode, String customEncoding) {
Reply to: