multi-os-engine
Investigate the possibility of implementing a bridge between GDB and JDI
Currently Native-Image can generate debugging information that can be used by GDB: https://www.graalvm.org/reference-manual/native-image/DebugInfo/
And some common debugging features are supported, including:
- break points configured by file and line, or by method name
- single stepping by line including both into and over function calls
- stack backtraces (not including frames detailing inlined code)
- printing of primitive values
- structured (field by field) printing of Java objects
- casting/printing objects at different levels of generality
- access through object networks via path expressions
- reference by name to methods and static field data
If we could create a translator between GDB and JDWP, then we could be able to use a java debugger to debug a native-image executable.
Apparently the debug info is not available for LLVM backend.
What do you mean or where do you take this from? What I saw in the code and what I tested, debug info is included with the llvm backend too. I can attach gdb to a programm, set breakpoints etc.
Apparently the debug info is not available for LLVM backend.
What do you mean or where do you take this from? What I saw in the code and what I tested, debug info is included with the llvm backend too. I can attach gdb to a programm, set breakpoints etc.
But there is no debug information about the original Java code, e.g., the file path, line numbers etc.
//EDIT Oh I found a mistake. I was just lucky that I got a example test case where this was working good. With another test with another programm it seems that the debug info is pretty buggy. But this should be something that can be fixed with the llvm backend because it is as I think just a bug. So some parts of my first response are outdated. //EDIT END
But there is no debug information about the original Java code, e.g., the file path, line numbers etc.
Yes, the original source code files is just put into a "sources" folder. But this is also true for non llvm-backend. But line numbers and file path, method names etc. are saved. e.g. I can run "break de/berstanio/x/x.java:50" and it works without the "sources" folder or any other source files. And why should we need the original source code included anyway? We would see the source code over e.g. Android Studio. And in GDB the original source code is just used to print the source code line afaik.
I can run "break de/berstanio/x/x.java:50" and it works without the "sources" folder or any other source files.
Are you sure this works for LLVM backend?
Yes but it only works partially as I know found out. What I missed on my testing was that I just tested to set the breakpoint on the first instruction on the method which is working on the llvm backend (I later thought that the other breakpoints weren't working were just a bug). But the other debug infos are gathered over the "sourceMapping" field in the CompilationResult class. And here only the standard "CompilationsResultBuilder" puts in informations, currently not the llvm backend. Therefor setting the breakpoint on the first instruction of the method works, on other places sadly currently not.
~~Btw. I now looked deeper in the code and I'm pretty confident that implementing the complete debbuging feature to the llvm backend should be quite simple.~~ How wrong I was, type info emition is way more complicated than I thought.
In case you haven't seen it already: https://blog.jetbrains.com/idea/2022/06/intellij-idea-2022-2-eap-5/ https://plugins.jetbrains.com/plugin/19237-graalvm-native-debugger "Experimental GraalVM Native Debugger for Java" Looks interesting @Noisyfox !
It seems that the llvm debugging is pushed forward by https://github.com/oracle/graal/pull/4964 It is currently function wise at the same level as my WIP
Seems graal native-image team is working on something like that themselves now: https://github.com/oracle/graal/issues/5648