Debugging Information for @RawStructure and @CStruct.

[christianhaeubl]

Some parts of Native Image (JFR support, GC, ...) define C-like structures via the annotations @RawStructure and @CStruct. At the moment, it seems that no debugging information is getting emitted for structs like that. Just in case that you want to add this support, NativeLibraries.findElementInfo(...) would be the starting point to query information about those structs. /cc @olpaw

[adinn]

Hi @christianhaeubl. Yes, it seems like it would be of great use to be able to recognise these types.

I'll look into the information that NativeLibraries.findElementInfo(...) returns and come back with an indication of what info we might be able to encode for these types, how we might need modify the debug info generator to do so and how much work it would entail.

[adinn]

@christianhaeubl @olpaw

I looked into this and I think it may well be possible to use the element info data to provide richer debug info for types derived from WordBase and PointerBase. I have some initial ideas for how to do this. However, before doing that I need to clarify some details.

1. The element info appears only to be present for types that subclass WordBase (which, therefore, includes those that subclass PointerBase). Is that always going to be the case? Or are there classes with element info that do not subclass WordBase?

2. I looked through the list of classes returned by heap.getUniverse().getTypes() to see which ones were subclasses of WordBase. I also checked which of them have element info. The summary counts are shown below.
   Clearly, a lot of them do not model foreign struct types. Is there any default interpretation that can be used to describe the classes which have no element info? For example, are they all really just the equivalent to a typedef for a machine word?

#Subclasses	#With Element Info	#No Element Info
176	87	89

(n.b. I edited this as I originally double counted the entries)

3. WordBase and its subclasses are currently presented as interfaces which means they are type compatible with (assignable to) type Object. That's obviously inappropriate for struct types since it implies they have a Java object header embedded at offset 0. Is there a good reason why they are typed using interfaces?

4. I am currently thinking that WordBase types with element info need to be described as pointers to foreign C struct/class types whereas those that have no element info need to be described as typedefs for a machine word or, when they inherit from PointerBase, a machine pointer. Is that the right model? In the latter case is there anything that would indicate signedness for the non-pointer word types?

[christianhaeubl]

Thanks for looking into that!

ad 1. WordBase is always the top-level type.

ad 2. The default interpretation is really just the equivalent to a typedef for a machine word. The typical uses are:

• C-style pointer to raw memory
• C-style pointer to a struct (i.e., the cases where there is some element info)
• some signed or unsigned value that has the size of a machine word but enough special meaning that it warrants a separate type (e.g., a file descriptor, a function pointer, ...)

ad 3. Right, they are type compatible with Object at image build time but there is a lot of magic happening to ensure that we don't mix WordBase types with normal Java objects at run-time (e.g., WordBase and Java objects can't be compared or assigned to each other at run-time and this checked during the image build). There is a small number of types, where we simulate WordBase types during the image build (i.e., a normal Java class implements a WordBase type interface, see HostedImageCodeInfo) but I don't think that this is relevant for the debug information support.

ad 4. The approach sounds good - regarding signedness: we don't have a lot of information on that, I think it is reasonable to assume that all types are unsigned except when they inherit from SignedWord.

[adinn]

Thanks for the explanation, @christianhaeubl. Mostly, I think that clarifies the requirements -- leaving me just to resolve a few (re-)design issues that I really need to consider regarding how to communicate the type info to the debug generator and then encode it as DWARF and, later, PECOFF. The only topic I think still needs more discussion is how to deal with Java instance classes that implement WordBase as an interface rather than as a marker for a machine word/pointer.

The first thing I need to clarify is how to recognize these special cases -- I'll call them WordBase implementors for want of a better name. It looks as if what you are talking about are the classes that appear in the universe's type list (the one returned by heap.getUniverse().getTypes()) as a HostedClass, specifically a HostedInstanceClass, rather than as a HostedInterface -- e.g. com.oracle.svm.core.meta.MethodPointer. Is that the exact criterion?

I also have a follow-up question regarding the status of some of the interfaces associated with these WordBase implementors but we'll need to discuss a second point before coming back to that.

That second point is what to do about the fact that WordBase (also PointerBase and, perhaps, other interfaces) is being used with two different interpretations. In some uses it, or its sub-interfaces, simply denotes values of a foreign integral/pointer type. In other uses it denotes objects that implement a Java interface. Clearly, the former is the predominant case. In order to deal with that first use the generic debug info model and its derived DWARF/PECOFF encodings will need to decouple types like WordBase, PointerBase and their derivatives from their presentation as an interface and regard them as standing outside of the Java type system. However, for WordBase implementors, such as HostedImageCodeInfo, a complete, correct debug model and DWARF/PECOFF encoding is supposed to recognize the implementor as a Java class which extends a Java interface also called WordBase (or PointerBase, etc). Other occurrences of WordBase (PointerBase etc) elsewhere in the model, say as the type of a field, local var, method parameter or target, etc, are expected to alias to type HostedImageCodeInfo.

Obviously the GraalVM code -- in particular, the compiler -- includes logic to recognize where these interfaces are being used with one or other interpretation and processes them correctly. However, that semantic distinction is not available to the debug info generator which presents us with a problem. The debug info model and underlying DWARF/PECOFF encoding cannot define a single type that sometimes functions as an interface and sometimes as a foreign primitive integral or pointer type.

One option would be to model them as two different types (which really implies using different names in order to allow them to be disambiguated on the gdb command line). However, that results in a hole in the type system -- for both the generic model and the DWARF/PECOFF encoding -- where the type compatibility of any WordBase implementor with other occurrences of WordBase in the type model (e.g. as the type of a field, local or method param) is no longer captured in the model. There is actually another alternative, which suffers the same problem as the last one but is arguably no worse. We could finesse the type mismatch by simply dropping WordBase, PointerBase and other intermediate interfaces from the implements list for a WordBase implementor. The type compatiblity hole is still there but we just don't see any evidence of it.

That brings us back to my follow-up for the recognition question. The problem here is that the interface hierarchy between WordBase and an implementor can contain interfaces which function as proper interfaces and not as foreign pointer markers. Looking at class HostedImageCodeInfo the interface hierarchy is:

  WordBase
    PointerBase
      UntetheredCodeInfo
        CodeInfo
          CodeInfoImpl
            HostedImageCodeInfo

Obviously, WordBase and PointerBase function as interfaces wrt HostedImageCodeInfo but we would want to model them as foreign integral and pointer types, respectively. However, it is not clear what to do about the other interfaces in the hierarchy. UntetheredCodeInfo is an empty interface and appears to function simply to mark a specific type of raw pointer. By contrast, CodeInfo appears to be used to type and manipulate actual CodeInfo Java objects (e.g. as a field in class CodeInfoTable, etc) as well as define some interface constants. So, CodeInfo and its sub-interfaces really need to be retained in the model as interfaces, type-compatible with class HostedImageCodeInfo. Of course, if we do that then we have to break the extends hierarchy at UntetheredCodeInfo. Whatever decision we take regarding replicating or dropping interfaces below WordBase we would really need to stop at UntetheredCodeInfo and retain proper interface definitions form CodeInfo down.

Clearly, I am interested to confirm my understanding of the use/meaning of the interfaces in this specific case. However, I also want to establish that the 'recognition' problem extends to cases like this i.e. we need some criterion which will distinguish cases where we retain the interface as an interface versus model it as a foreign integral or pointer type. We can always do something ad hoc but a more principled approach would be preferable.

Finally, I have a suggestion that might allow this problem to be bypassed. I think it is best explained using CodeInfo as an example. CodeInfo, CodeInfoImpl and HostedImageCodeInfo only inherit from the foreign pointer/word interfaces further up the hierarchy in order to be able to advertise themselves as implementing the API defined on those parent classes e.g. WordBase::rawValue, PointerBase::isNull etc. However, when operating on a HostedImageCodeInfo object via its implementation type or either of those two immediate parent types we are not interested in the fact that it can also be processed as a raw pointer/word, as we are for uses of the value via type UntetheredCodeInfo, and in some cases where it is used via types PointerBase and WordBase. We can decouple these concerns by factoring the API and foreign type marker behaviours into independent interface trees

interface WordBase {
  long rawValue();
  . . .
}
interface WordBaseRaw extends WordBase { }
interface PointerBase extends WordBase {
  boolean isNull();
  . . .
}
interface PointerBaseRaw extends PointerBase, WordBaseRaw { }
interface UntetheredCodeInfo extends PointerBase { }
interface UntetheredCodeInfoRaw extends PointerBaseRaw { }
interface CodeInfo extends UntetheredCodeInfo {
  ...
}
interface CodeInfoImpl extends CodeInfo {
  ...
}
class HostedCodeInfo implements CodeInfoImpl {
  ...
}

The resulting class hierarchy is as follows

  WordBase ----------------------\
       |                          WordBaseRaw
    PointerBase -------------------\
         |                         PointerBaseRaw
      UntetheredCodeInfo ------------\
            |                        UntetheredCodeInfoRaw
        CodeInfo
          CodeInfoImpl
            HostedImageCodeInfo

Determining whether an interface models a foreign integral/pointer value boils down to testing whether it implements WordBaseRaw or PointerBaseRaw. CodeInfo and its subtypes are now clearly distinguished as Java types which cannot be confused with foreign pointer types. In particular, any classes which employ annotations that give rise to element info need to be in classes that inherit from PointerBaseRaw and not from PointerBase.

Clearly, introducing this split would mean retyping some of the code which is using interfaces WordBase or PointerBase to manage raw values as actual raw data rather than as implementors of the API. That might be a lot of work or might be fairly well localized.

[adinn]

n.b. It would also be possible to refactor as follows

  WordBaseAccess ----------------------\
       |                          WordBase
    PointerBaseAccess -------------------\
         |                         PointerBase
      UntetheredCodeInfoAccess ------------\
            |                        UntetheredCodeInfo
        CodeInfo
          CodeInfoImpl
            HostedImageCodeInfo

This would mean that it would only be necessary to retype occurences of WordBase etc to WordBaseAccess etc at locations in the code where both a raw pointer or an Object might be the target of the operation.

[christianhaeubl]

@adinn: thanks for the detailed explanation.

• Regarding types such as HostedImageCodeInfo: types like that only exist during the image build but not at run-time. So, I think that the debug information support can just skip all classes that implement WordBase (only the interfaces are relevant). That is what I meant when I wrote "... not relevant for the debug information support ..." above. Sorry for not being precise enough.

• Regarding constants, that are defined in interfaces such as CodeInfo: for now, I would suggest to ignore those so that no debug information is emitted. If we need debug information for them, then it is probably easier to just move them to another class (e.g., CodeInfoAccess).

[adinn]

Hi @christianhaeubl Thanks for further clarification. Obviously, if these implementation classes never actually appear in the hosted universe then there is no problem. I'll put in an assert that any WordBase derived type found in the hosted universe is not an instance class.

As regards the constants, I don't think I have any leeway at present as far as modelling the fields is concerned. The debug generator does not currently get any say in what constants appear in the image. Final constant values are often folded into a single value in the heap and the fields (plural) which share a specific constant value are squeezed out of the image: so, when the generator looks at a final Field object belonging to some hosted type it is not associated with a heap offset. I assume some (primitive) constants get folded into code literals, so don't even give rise to some associated heap value. It would be nice for debugging purposes if it were possible for the debug generator to make an association between constant fields and the values they represent but that is a future project.

[adinn]

Hi @christianhaeubl, @olpaw I added an assert to the current code and it broke things right away -- success!

Of course, what is clear is that the hosted/analysis universe does include WordBase derived instance classes. When building a simple hello world program a call to heap.getUniverse().getTypes() mentions the following implementors:

• org.graalvm.compiler.word.Word
• org.graalvm.compiler.word.HostedWord
• org.graalvm.nativeimage.impl.CEntryPointLiteralCodePointer
• com.oracle.svm.core.meta.MethodPointer

I did a quick scan of the generated debug info to check whether these types were included because they were needed to describe other types in the type system:

1. There are many cross-references to the debug info generated for Word
   e.g. as the return type of ReferenceAccessImp::readObjectAsUntrackedPointer
   or as the type of local variable w in ReferenceAccessImp::readObjectAt
   All such references appear to occur in method parameter/return type info or local variable type info, both for top level method info and for inlined method info.
2. There are no cross-references to the debug info generated for HostedWord
3. There are no cross-references to the debug info generated for CEntryPointLiteralCodePointer
4. There are no cross-references to the debug info generated for MethodPointer

Clearly, Word is included because there are many places where it is needed to provide a complete type closure. I was not sure there is any good reason to include the classes in the latter three cases so I took a look.

I debugged the analysis to find the first point where HostedWord gets inserted in the analysis universe. This happened compiling CEntryPointSnippets::isAttachedSnippet. This method refers to field CEntryPointSetup::SINGLE_ISOLATE_SENTINEL which is of type org.graalvm.compiler.word.Word and gets initialized by calling value WordFactory.unsigned(0x150_150_150_150_150L) (obviously there are many other cases like this one).

The analysis reflection provider (AnalysisConstantReflectionProvider) process this field reference under method readValue(). It calls readUninitializedStaticValue() which creates a DirectObjectConstant pointing to a HostedWord with 0x150_150_150_150_150L as its rawValue. The call to interceptValue at the end of readValue() ends up inserting class HostedWord into the analysis universe (via a call to lookupJavaType()) because it is the class of the object referenced by this DirectObjectConstant. Of course, the only reason it is a HostedWord rather than the type it is create as UnsignedWord is because Word::boxImpl(long) is defined as

public <T extends WordBase> T boxImpl(long val) {
    return (T) HostedWord.boxLong(val);
}

As far as any use of this constant is concerned it is simply a Word or an UnsignedWord.

I'm not certain that anything really requires HostedWord to be added to the universe. However, it certainly doesn't look like it should. So, its presence is just an unfortunate outcome of the way the current analysis code goes about checking type compatibility. As far as any processing of the value is concerned it looks like it will be treated as if it is a pointer i.e. handled in code as a long.

So, I went on next to see where CEntryPointLiteralCodePointer gets added. This occurs under a lambda defined in ImageHeapScanner::createImageHeapObject which passes a DirectObjectConstant through to ImageHeapScanner::onFieldValueReachable. The constant in question has as its object an instance of CEntryPointLiteralCodePointer. This was created to initialize field CEntryPointLiteral::functionPointer of some instance of CEntryPointLiteral. The code helpfully suggests that this field is accessed using an alias. Unfortunately, the constant itself gets passed into AnalysisConstantReflectionProvider::interceptWordType() and, as before, this leads to the inclusion of CEntryPointLiteralCodePointerin the analysis universe.

Finally I repeated the same exercise for MethodPointer. This gets inserted under a compile for SubstrateIdentityHashCodeSnippets::computeIdentityHashCode. The DirectObjectConstant in question here appears to be an instance of class NamedLocationIdentity used as value for field IdentityHashCodeSupport::IDENTITY_HASHCODE_LOCATION. This one seems to be really weird though. Method SharedConstantFieldProvider::isFinalFieldValueConstant checks whether the constant is a MethodPointer by calling metaAccess.isInstanceOf(value, MethodPointer.class). The resulting call to AnalysisMetaaccess::lookupJavaType inserts MethodPointer into the analysis universe.

I'm not sure exactly what to do about these 3 cases. It seems like what I should do is ignore the fact that these are classes and instead generate info for them as though they are opaque foreign pointer types -- i.e. they are addresses whose target type is unknown.

I am not sure if that is also appropriate for the compiler Word type. It is already the case that the debug info is expecting values of this type (i.e. constants on the heap, in stack slots or in registers) to be a long word. Is the right thing to do to treat all WordBase derived classes as opaque foreign pointers?

[christianhaeubl]

Thanks for checking. Yes, Word, HostedWord, CEntryPointLiteralCodePointer, and MethodPointer are all machine word-sized values at runtime, so it should be fine to simply ignore the fact that these are classes and to generate the debug info as if they were opaque foreign pointer types.

[adinn]

Fixed by #6774