You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
oracle/graal@dee66ca (included in GraalVM/Mandrel >=21.1) started enforcing the use of absolute paths in DW_AT_comp_dir. These paths are essentially pointing to the location of the "sources" directory holding the source code corresponding to the binary being debugged. In Quarkus we copy the "sources" directory after the compilation is done:
As a result the absolute paths written in the DW_AT_comp_dir entries become invalid and thus the user needs to invoke directory path/to/sources in gdb to let it know where to find the sources. This was optional prior to 21.1 as long as gdb was started from the same directory containing the sources directory. This last part made debugging on deployment environments a bit easier as well, since the user could copy the sources directory next to the binary and start gdb from there without any additional configuration.
Expected behavior
When running gdb in the target directory, it should be able to detect the sources without additional configuration.
Actual behavior
gdb requires using directory to point it to the sources directory.
How to Reproduce?
Compile an application with -Dnative and -Dquarkus.native.debug.enabled=true
Enter target directory and run gdb <my-app-runner>
Run info func <part of a method name in the app> to get a method
Try to list that method, e.g. list myMethod
Output of uname -a or ver
No response
Output of java -version
No response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
No response
Build tool (ie. output of mvnw --version or gradlew --version)
No response
Additional information
No response
The text was updated successfully, but these errors were encountered:
zakkak
changed the title
gdb debugging of native images without setting the sources directory no longer works as of 21.2
gdb debugging of native images without setting the sources directory no longer works as of 21.1
Sep 22, 2021
zakkak
changed the title
gdb debugging of native images without setting the sources directory no longer works as of 21.1
gdb debugging of native images without setting the sources directory no longer works as of GraalVM/Mandrel 21.1
Sep 22, 2021
Describe the bug
oracle/graal@dee66ca (included in GraalVM/Mandrel >=21.1) started enforcing the use of absolute paths in DW_AT_comp_dir. These paths are essentially pointing to the location of the "sources" directory holding the source code corresponding to the binary being debugged. In Quarkus we copy the "sources" directory after the compilation is done:
quarkus/core/deployment/src/main/java/io/quarkus/deployment/pkg/steps/NativeImageBuildStep.java
Lines 226 to 230 in 5b91e61
As a result the absolute paths written in the DW_AT_comp_dir entries become invalid and thus the user needs to invoke
directory path/to/sources
in gdb to let it know where to find the sources. This was optional prior to 21.1 as long as gdb was started from the same directory containing the sources directory. This last part made debugging on deployment environments a bit easier as well, since the user could copy the sources directory next to the binary and start gdb from there without any additional configuration.Expected behavior
When running gdb in the
target
directory, it should be able to detect the sources without additional configuration.Actual behavior
gdb requires using
directory
to point it to the sources directory.How to Reproduce?
-Dnative
and-Dquarkus.native.debug.enabled=true
target
directory and rungdb <my-app-runner>
info func <part of a method name in the app>
to get a methodlist myMethod
Output of
uname -a
orver
No response
Output of
java -version
No response
GraalVM version (if different from Java)
No response
Quarkus version or git rev
No response
Build tool (ie. output of
mvnw --version
orgradlew --version
)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: