[NativeAOT] Natvis visualization for threadstatic variables.

[VSadov]

Fixes: #89227

The change implements visualization for threadstatic variables in common cases.

The essence of the change:

=== Uninlined case:

• For reliability reasons the threadstatic storage is all managed in 8.0 (vs. mix of native/managed in 7.0).
  Made corresponding adjustments for indexing of native vs. managed arrays in the natvis.
• Adjusted natvis for renames and removal of redundant m_numThreadLocalModuleStatics

=== Inlined case

• Since TypeThreadStaticIndexNode is needed for natvis, start emitting TypeThreadStaticIndexNode for inlined types as well. (we stopped emitting that for inlined threadstatics since the index is not needed at run time)
• Added support in natvis to detect inlined case and interpret TypeThreadStaticIndexNode accordingly
  (that is mostly to treat the offset not as an index of the storage block, but an offset within the storage block)

=== overall

• added more comments in a few places
• refactored natvis a bit to make it a bit less painful to read

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes: #89227

Author:	VSadov
Assignees:	VSadov
Labels:	area-NativeAOT-coreclr
Milestone:	-

[VSadov]

This is how threadstatics visualization looks in optimized builds.
( S_P_CoreLib_System_Threading_Thread::__THREADSTATICINDEX.Get() is the incantation to get to threadstatics of
System.Threading.Thread)

[VSadov]

This is the same view using Debug (unoptimized build)

There are no differences, but a curious user can do ConsoleApp32_Program::__THREADSTATICINDEX.IsInlined() and see if the type uses inlined storage.

[VSadov]

Limitations:

• generic types are not supported
  This never worked, not even for Something<int>, for which we do emit the TypeThreadStaticIndexNode and have all information necessary.

Natvis is a terrible language for doing anything complex and appears to be unable to parse nested generic types which arise when we need to visualize for a generic instantiation.

A typical failure looks like the following (both 7.0 and 8.0):

This is visualizing System.Buffers.TlsOverPerCoreLockedStacksArrayPool<Char>

If you notice S_P_CoreLib_System_Buffers_TlsOverPerCoreLockedStacksArrayPool_1<Char>::__THREADSTATICINDEX is present, but it's Get() fails to light up.

The natvis diagnostics contains

    Error while evaluating '*(__type__THREADSTATICSS_P_CoreLib_System_Buffers_TlsOverPerCoreLockedStacksArrayPool_1<Char>>**)(&(*GetStorage()).values)[ClassIndex]' in the context of type 'ConsoleApp32.exe!__ThreadStaticHelper<__type__THREADSTATICSS_P_CoreLib_System_Buffers_TlsOverPerCoreLockedStacksArrayPool_1<Char>>'.

The unbalanced extra > in TlsOver<Char>>** appears to be a result of incorrect unwrapping of a nested generic helper. Possibly a bug in the natvis parser.
We pattern match __ThreadStaticHelper<*> and use the match in ($T1*), and in a generic case, T1 ends up having an extra >.

[VSadov]

This is the key change. We used to create just one _inlinedThreadStaticsIndex node for the entire storage block in inlined case and were reusing the node for every type involved.
Now we are back to having individual index nodes for all types that have threadstatics. This allows natvis to know the offsets of each type's storage within the block.

[VSadov]

Another limitation:

• Sometimes, if the case is simple enough, the visualization does not work.

For example a threadstatic like

class c1
{
    [ThreadStatic]
    public static int tt;
}

Such threadstatic would be completely functional - i.e. c1.tt can be assigned/read/incremented, but cannot be visualized.

	Name	Value	Type
	ConsoleApp32_c1::__THREADSTATICINDEX.Get()	identifier "ConsoleApp32_c1" is undefined

I think in simple cases we may be dropping/trimming away parts which are important for the visualization.
This can happen regardless of Release/Debug or 8.0/7.0

[jkotas]

Report it in ComputeNonRelocationBasedDependencies

runtime/src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/DependencyAnalysis/ReadyToRunHelperNode.cs

Line 123 in a19585d

protected override DependencyList ComputeNonRelocationBasedDependencies(NodeFactory factory)

[VSadov]

I will look into using that.

The tricky part is to not root threadstatic index for every type that has threadstatics, but only for those that are reachable in the code, even though the index itself is not used.
(technically the index node is “used” - at compile time, and maybe debug time, but the code itself, once emitted, does not need the index)

[VSadov]

Although, I think, we can assume that for every type with inlined storage the index will be "used", since we build the storage block based on the analysis that we did in the scanner.

[VSadov]

I just made the node that describes the storage block report as static dependencies the index nodes for the types whose storage is inlined in the block.

[jkotas]

Thank you!

[VSadov]

Thanks!!!

[kunalspathak]

@VSadov - what changes are needed once we have #89472?

[VSadov]

I do not think any changes are necessary. The shape of TLS is not changing, so this should keep working. (I will confirm, just in case)

[kunalspathak]

Here is what I see:

[VSadov]

Yes, that looks functional. The natvis script digs into the TLS structure on the runtime side and knows about possible shapes, so the visualization should work regardless of how TLS is accessed from the code.