Static members debug information

[kbaladurin]

How can I get value of the class's static member in VS? Sample:

using System;
using System.Collections.Generic;
using System.Runtime.CompilerServices;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    public static int s_int = 10;
    public static int[] s_arr = new int[10];
    public int a = 42;

    static int Main()
    {
        var a = new Program();
    Program.s_int = 20;
        return 0;
    }
}

Result (Immediate Window):

a
{a=42 }
    Object: {m_pEEType=0x00007ff60c59c1c0 {BasicThreading.exe!const BasicThreading_Program::`vftable'} }
    __vfptr: <Unable to read memory>
    a: 42
a.__NONGCSTATICS
class "BasicThreading_Program" has no member "__NONGCSTATICS"
a.__GCSTATICS
class "BasicThreading_Program" has no member "__GCSTATICS"

Thank you!

[kbaladurin]

PTAL @sandreenko @davidwrighton

[kbaladurin]

Also gc, non-gc and thread statics are represented by corresponding artificial static members. Why was this way chosen? I think without such grouping debugging will be more comfortable.

[MichalStrehovsky]

How can I get value of the class's static member in VS?

This isn't implemented yet. Currently the only way to inspect these is to look at the symbol and interpret the bytes manually.

Also gc, non-gc and thread statics are represented by corresponding artificial static members. Why was this way chosen?

Thread statics would have to be special no matter what. We distinguish between GC and non-GC statics for perf reasons. GC statics are allocated on the GC heap and if we were to lump them together, all of them would need to be on the GC heap. Non-GC static fields can be accessed faster because their address is known at compile time. GC static bases need to go through indirections because GC can move them around.

To provide a nice debugging experience for statics, we'll likely need to build a small thing on top of what native debuggers provide out of the box. It might be possible with some NatVis magic and extra debug records, but I haven't really looked into that.

[kbaladurin]

@MichalStrehovsky thank you!