Synchronize GraalVM upstream's and Quarkus'-only debug info stripping

[jerboaa]

Describe the bug

GraalVM 23.0 will gain functionality to strip debuginfo. This is turned on by default when debuginfo generation is being turned on. As a result, quarkus applications trying to turn on debuginfo and then trying to use it in a debugger results in a CRC mismatch when loading them with gdb (for example):

warning: the debug information found in "/disk/graal/upstream-sources/mandrel-integration-tests/apps/quarkus-full-microprofile/target/quarkus-native-image-source-jar/quarkus-runner.debug" does not match "/disk/graal/upstream-sources/mandrel-integration-tests/apps/quarkus-full-microprofile/target/quarkus-native-image-source-jar/quarkus-runner" (CRC mismatch).

This is caused by two .gnu_debuglink sections trying to get created. The first one by GraalVM, the second by quarkus's native image build steps. The second attempt will fail and then the debuginfo won't match the CRC.

Expected behavior

Either use upstream's feature or turn it off using -H:-StripDebugInfo and keep using quarkus's approach.

Actual behavior

Debuginfo isn't working. See:
Karm/mandrel-integration-tests#138

How to Reproduce?

Build a quarkus up in native with a GraalVM 23.0.0 snapshot build with debuginfo. Try to debug the binary in gdb. Observe the CRC warning and debuginfo not usable for source-file-based break points.

Output of uname -a or ver

No response

Output of java -version

17.0.7+1

GraalVM version (if different from Java)

23.0.0

Quarkus version or git rev

main

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @Karm (mandrel), @galderz (mandrel), @zakkak (mandrel)

[jerboaa]

Note that upstream GraalVM's functionality currently is inferior to the quarkus impl as the upstream version uses absolute paths for the debug link. Making it less usable (the chance of the path being the same on the build host and the debug host is pretty slim; expecially for in-container builds). I'll get an upstream GraalVM issue filed today.

[jerboaa]

Note that upstream GraalVM's functionality currently is inferior to the quarkus impl as the upstream version uses absolute paths for the debug link. Making it less usable (the chance of the path being the same on the build host and the debug host is pretty slim; expecially for in-container builds). I'll get an upstream GraalVM issue filed today.

Hmm, so this doesn't seem to be the case. For a simple hello-world:

>> objcopy --only-keep-debug /disk/graal/upstream-sources/graal/mandrel-build/hello /disk/graal/upstream-sources/graal/mandrel-build/hello.debug
>> objcopy --strip-all --keep-symbols=/tmp/SVM-11047642624609900473/keep-symbols.list /disk/graal/upstream-sources/graal/mandrel-build/hello
>> objcopy --add-gnu-debuglink=/disk/graal/upstream-sources/graal/mandrel-build/hello.debug /disk/graal/upstream-sources/graal/mandrel-build/hello

Then looking at the debuglink we see it being relative:

$ readelf -p .gnu_debuglink hello

String dump of section '.gnu_debuglink':
  [     0]  hello.debug
  [     e]  {�

Looks like objcopy is smart enough (and/or the man page is outdated). Either way, this is a non-issue (or at least I'm not able to reproduce).

[jerboaa]

Looks like objcopy is smart enough (and/or the man page is outdated). Either way, this is a non-issue (or at least I'm not able to reproduce).

For the record, I've reached out to Nick Clifton and clarified this point. It's merely an outdated code comment that the path to files need to be relative and he'll submit a patch to fix the wrong comment. Since the embedded path will only be relative it exposes an interesting problem, though. Only well-known-locations are being searched for debuginfo files. This shouldn't be a problem for our case, though, as the directory where the binary is located is one of them.