---

This section details on the original issue you should resolve

<issue_title>No DWARF debug info generated when accessing fields on a null object unless explicitly instantiated</issue_title>
<issue_description>### Description

When testing .NET and OS-level signal/exception handling, I found an issue where certain code patterns fail to generate DWARF debug info. Specifically, the following code does not generate DWARF debug information:

public class NullObjectTest
{
    public int aaaaa1;
    public int aaaaa2;
    public int aaaaa3;
    public int aaaaa4;
    public string aaaaa5;
    public string aaaaa6 => aaaaa5;
    public object aaaaa7;
}
var nullObj = (NullObjectTest)null;
nullObj.aaaaa4 = 1;

The issue occurs unless the user explicitly instantiates (e.g., new) the class. This was discovered during low-level signal handling tests, where I encountered unexpected behavior in the ILC output.

Reproduction Steps

1. Create the class NullObjectTest as shown above.
2. Assign var nullObj = (NullObjectTest)null;
3. Try accessing or assigning a field, e.g., nullObj.aaaaa4 = 1;
4. Build and inspect the generated DWARF debug info.
5. Observe that no DWARF debug information is created for this code pattern unless NullObjectTest is instantiated via new.

Expected behavior

DWARF debug info should be generated even when fields are accessed or assigned on a variable that is statically typed but not explicitly instantiated (i.e., is null).

Actual behavior

No DWARF debug info is produced for the code above when not explicitly instantiating the object. This limits debugging and inspection during signal exception or crash analysis. The issue seems specific to certain IL patterns generated by the compiler.

Regression?

I am not sure if this is a regression. It was noticed during custom OS signal exception testing. Unsure if previous builds had the same behavior.

Known Workarounds

Explicitly instantiate the class:

var obj = new NullObjectTest();
obj.aaaaa4 = 1;

This allows DWARF debug info to be generated as expected.

Configuration

Observed with latest .NET. Please clarify if specific OS/platform details are needed.

Other information

Discovered when testing OS signal/exception mechanisms and analyzing ILC output. Might be related to compiler optimization for null values.

Proposed fix (reported by reporter):

• File: src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/UserDefinedTypeDescriptor.cs
• Method: GetClassTypeIndex
• Change: remove or comment out the guard that skips types without instance fields:

Current code to change:

if (!hasInstanceFields)
    continue;

Rationale: That guard causes types that are referenced as a null variable (no explicit new) to be skipped when emitting type/field metadata used for DWARF generation. Removing/commenting out it ensures the type is considered and DWARF debug info (field/location info) will be generated even when the variable is null at compile-time.</issue_description>

Comments on the Issue (you are @copilot in this section)