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