Add debug info feature to CE native image generator

[adinn]

Red hat would like to work with the GraalVM project to add debug info to the native image generator for use by command line debuggers and IDEs. The generated debug info should include:

• symbols for primitive, object and interface types
• symbols for methods
• size and numeric type info for Java primitive data
• size and layout info for Java object data
• address ranges for method code
• file and line number info for specific code addresses within methods
• method frame layouts at end of method prologue and at specific addresses within calls
• parameter and local var type and location info (register/stack/memory) at end of method prologue and at specific addresses within calls
• address and type for Java primitive and object values located in the heap region

We believe it should be possible to use this info to support the following iniital debugging functionality:

• 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 necessarily including frames detailing inlined code)
• structured display of primitive values and objects
• including display of data accessed through object networks via path expressions

Debug info should cover both app code and JDK Runtime/SubstrateVM code and types.

The current plan is to implement a working version for ELF/Linux using DWARF info. This will be verified using gdb as the target debugger. This will proof the idea and also identify a model for plugging in the capability as a Native Image Generator feature. A follow up task will attempt to provide equivalent debug info to support denbugging for Windows/PECOFF and MacOS/MACHO images.

[adinn]

I'd be grateful if anyone, particularly Oracle staff, would care to comment on the proposed feature list and/or associated debug info that I envisage need to be injected into native images. I have made considerable progress with a prototype implementation of some of these features which I hope to make available soon for early review. It would be very helpful to know what others consider to be priorities for that implementation.

n.b. I am afraid I have no idea what features -- or, indeed, debug info -- the product code provides (I am deliberately not looking at the product behaviour or image object structure for reasons that I assume are obvious).

[dougxc]

The proposed feature set and the debugging capabilities it provides look like a very good start. I spoken a bit with @olpaw on this and some design considerations fell out of our conversation:

• Native image debug info should be modeled as independently as possible from a specific debug info format such as DWARF. Only in the backend should this model be converted to DWARF/PECOFF etc.
• You should use org.graalvm.compiler.code.CompilationResult.getSourceMappings() instead of org.graalvm.compiler.code.CompilationResult.getInfopoints() in terms of getting source line info.
• In terms of debugging experience, it might be worth considering debugger extensions (e.g. using gdb's python API) tha do things such as:
  • Simplify setting breakpoints based on Java names. For example: > ni-bp java.lang.Class.isAnonymousClass(java.lang.Object)boolean
  • pretty print values based on dynamic info. For example, DWARF may state that the static type of a variable is java.lang.Object but it may actually be java.util.ArrayList and reading through the object's header, better pretty printing is possible.
• You should also consider what's possible in terms of native debug info for runtime generated code (e.g. Truffle compilation in a native image runtime).

[olpaw]

• CompilationResult.getSourceMappings() should give you what you need for .debug_info and .debug_line
• CompilationResult.getMarks() can be used to build .debug_frame (use the MARK_PROLOGUE/EPILOGUE strings in SubstrateBackend derived classes as keys)
• To generate representations for types (DW_AT_type entries) you can make use of HostedUniverse.getTypes()

[christianwimmer]

Windows will be a supported platform for Native Image very soon, so it would be good to have Windows support from the beginning and not as a "follow up task".

If you plan the rely on any external library, please let us know as early as possible because all external dependencies have to go through an extensive approval process.

[adinn]

Thanks very much for the extremely helpful feedback.

I had already identified CompilationResult.getSourceMappings as the route to derive line info and HostedUniverse.getTypes() to derive type info. My current prototype uses the former to generate enough DWARF content to support line and method name based breakpoints and line-by-line stepping (i.e. so far I have abbrev, info, range and line sections). The info section does not yet locate methods records as members of an associated class as I have not added type info.

I have started looking into generating details of classes and I believe HostedUniverse.getTypes() will provide most of what is needed to generate the extra DWARF records needed to support most of the remaining functions.

Before moving on to cater for type info I need to complete derivation of debug info from the the CompilationResult suite with one last feature -- adding frame base fields to the DWARF info records that describe methods. That should be enough to allow stack backtraces to work (and also, eventually, allow specification of stack locations for locals relative to the frame base). I had already spotted CompilationResult.totalFrameSize() but had not yet seen CompilationResult.getMarks(). Clearly, that is is all I need in order to allow the debugger to identify the frame base. So, I also hope to have stack backtraces working in gdb fairly soon. I think it might be wise to post a PR for review once that is working.

As regards future work, I would very much like to have Windows support as well as DWARF for Linux in whatever gets committed. One of my colleagues is looking into implementing this. He is currently using Visual Studio and tailoring the PECOFF debug info that he generates to what it expects. Does the project assume a specific tool suite and version?

Regarding the front end/back end split, I understand this constraint. Indeed working around it was one of the trickiest things I needed to puzzle out in order to get started. I have located all the logic for generating DWARF debug within the same package as ElfObjectFile. Indeed, at the moment is is implemented using a single class called DwarfSections within which I have embedded static member classes that implement each relevant DWARF section as a suitable subclass of ElfSection. Class DwarfSections constructs a shared model of the underlying type/code/heap which the individual sections can reference in order to size and build their own content. Similarly, my colleague has located all the logic for generating VS debug info into PECoffObjectFile.

Obviously, making this work has required providing an abstraction layer on ObjectFile which allows the details of the underlying method, type and heap layouts to be presented to the ObjectFile implementation without the latter knowing anything about the underlying Substrate/Graal types. I have managed to implement such a split by adding a suite of interfaces to ObjectFile which allow Type, Code and Heap info to be queried in a generic way. These interfaces are implemented by classes defined in NativeBootImage in much the same way as it provides/overrides NativeTextSectionImpl. My DwarfSections class uses the interface API to interrogate the supplied implementations ad build its own internal model of the types, code and heap.

I am sure the way I have achieved this i) is less clean than is desirable and ii) does not conform to the model Graal employs for implementing add-on features. However, it does ensure that no change are needed to type visibility for the current various different Graal source modules/packages. No doubt when my prototype is ready for review you will have ample opportunities for feedback to help improve this decoupling :-)

Another interesting point of concern is the AArch64/x86_64 split. Provision of frame info is the first occurrence up to now in my prototype where the underlying hardware architecture influences (DWARF) debug info generation. On Linux/x86 I need to encode the frame base as an offset relative to RSP/RBP and on Linux/AArch64 it has to be relative to RSP/RFP. That requires generating different location codes because registers need to be referred to by index number (r7/r8 vs r31/r29). I believe I can finesse this and other such differences in generated content by delegating such occurrences to an arch-specific generator subclass internal to the DWARF generator suite, instantiating it modulo the ElfObjectFile arch setting.

Regarding library support I was not intending to use any external libraries. So far, I have used pure Java to write all DWARF content. Of course, the whole of DWARF is huge. However, implementing the subset needed to support debugging for native images ought not to be intractable. I don't think my colleague has any plans to use lbs for the Windows code but I will check that with him and get back to you.

I have looked into gdb's Python API in the past and actually managed to do so without resorting to fleeing the country and joining the Foreign Legion. It would indeed be nice, say, to specify method names using Java syntax or print an Object as an ArrayList where the relevant type inclusion relation held. I thought I could maybe leave this sort of fancy command processing to someone who actually knows and likes Python (hmm, ... Doug ... :-).

The possibility of generating debug info for gdb on the fly to handle dynamic compilation does sound very appealing. I am not sure whether the current gdb API to hand over DWARF info is actually ready for prime-time. I had a look into it a couple of years ago when trying to extend gdb to do stack backtraces for Hotspot and could not find an easy way to use it (despite talking through the problems with gdb devs). In the end I found it much easier to use the Python API to extend gdb so that it knew how to traverse the code heap and other Hotspot internal data structures in order to identify details of compiled methods. I will have a chat with some of the gdb devs to find out if anything has improved in the latest implementation.

[olpaw]

I am not sure whether the current gdb API to hand over DWARF info is actually ready for prime-time.

Yes, this is somewhat wacky. You have to use the interfaces defined in
https://sourceware.org/gdb/current/onlinedocs/gdb/Declarations.html#Declarations
to communicate runtime-compiled code created by the inferior to GDB. You can use it to point GDB to a dwarf section that you create in memory that corresponds to the debuginfo for the newly created code.

[dougxc]

I thought I could maybe leave this sort of fancy command processing to someone who actually knows and likes Python (hmm, ... Doug ... :-)

There could well be some existing work in this area that can be contributed once your initial implementation is in place ;-)