Debugger does not correctly handle bytes without a backing field. #9688
Description
NOTE: Relevant bits copied from https://github.com/dotnet/coreclr/issues/15694
Related Bugs: https://github.com/dotnet/coreclr/issues/10148
Any byte which is not explicitly covered by a field is not visible to the debugger. This includes padding bytes, additional bytes allocated by an explicitly sized struct, etc.
This is true when looking at the values via the locals window, watch windows, or immediate windows.
Ex 1:
struct Data
{
byte _0;
// implicit padding byte
// implicit padding byte
// implicit padding byte
int _4;
}The three implicit padding bytes are always 0 in the debugger. That is, when accessing via ((byte*)&data)[1] in the watch/immediate. There is no expectation for these bytes to be visible in the locals window.
Ex 2:
[StructLayout(LayoutKind.Sequential, Size = 16)]
struct Vector128<T> where T : struct { }All of the 16-bytes in Vector128<T> are implicit (no field exists that maps directly to those bytes), so all 16-bytes are always 0. Likewise, if viewing the raw bits via aliasing (((byte*)&data)[1]). There is no expectation for these bytes to be visible in the locals window.
Ex 3:
struct Vector<T>
{
private Register register;
}
[StructLayout(LayoutKind.Explicit)]
struct Register
{
[FieldOffset(0)]
internal Double double_0;
[FieldOffset(8)]
internal Double double_1;
// Other overlapping fields
}On an AVX machine, Vector<T> is explicitly sized to 32, so the latter 16 bytes (which are not directly mapped to a field) are not accessible. This is expected to work in the immediate, watch, and locals window
Ex 4:
internal unsafe struct MyBuffer
{
public fixed char fixedBuffer[128];
}The full set of 128 values are expected to be visible in the locals window, much like an actual array would allow. They should likewise be visible via evaluation in the immediate or watch window, such as via myBuffer.fixedBuffer[5].