[cDAC] Support passing global string values

[max-charlamb]

Will be used in #113899 to pass target runtime identifier.

To support passing global strings, I have modified the data descriptor spec. Previously globals were of the form

[ VALUE | [int], "type name" ]
or
VALUE | [int]

Where the VALUE may be a JSON numeric constant integer or a string containing a signed or unsigned decimal or hex (with prefix 0x or 0X) integer constant.

I have modified VALUE to be less constrained: VALUE may be either a number or a string. JSON numeric constants are always parsed as numbers. JSON strings are always parsed as strings and may additionally parse as a hex (with prefix 0x or 0X) or decimal number.

To fit the new spec, the cDAC data contract implementation was modified in three main:

• The datadescriptor.h and datadescriptor.cpp in the runtime.
  • Added mechanism CDAC_GLOBAL_STRING(name, value) to pass global strings which are a mapping of a string (name) to string (value). Both strings exist in the existing string pool.
• The cdac-build-tool which takes the obj file and converts it to a JSON human readable contract.
  • Modified to parse global strings from the obj and properly convert to JSON.
• The parser inside of cdacreader which reads the JSON into a Target.
  • Modified to parse global strings and allow fetching existing stringy number globals as strings.

With this change existing stringy numbers can be parsed as either a number or a string.

Example:

{
  "globals": {
    "stringValue" : "Hello world",
    "stringyInt" : "1234",
    "stringyHex" : "0x1234",
    "int" : 1234
  }
}

target.ReadGlobalString("stringValue"); // "Hello world"
target.ReadGlobal<ulong>("stringValue"); // Exception!! cannot be parsed as a number

target.ReadGlobalString("stringyInt"); // "1234"
target.ReadGlobal<ulong>("stringyInt"); // 1234

target.ReadGlobalString("stringyHex"); // "0x1234"
target.ReadGlobal<ulong>("stringyHex"); // 4660 (0x1234)

target.ReadGlobalString("int"); // Exception!! no string representation for JSON Numbers
target.ReadGlobal<ulong>("int"); // 1234

[Copilot]

Pull Request Overview

This PR adds support for passing global string values to the data contract reader and descriptor model. Key changes include:

• Introducing new fields and APIs for global strings in targets and builders.
• Enhancing test coverage with new tests for reading global string values.
• Updating the build tool and parser to handle global string specifications in the data descriptor blob.

Reviewed Changes

Copilot reviewed 10 out of 14 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/native/managed/cdacreader/tests/TestPlaceholderTarget.cs	Added global strings field and TryReadGlobalString method.
src/native/managed/cdacreader/tests/ContractDescriptor/TargetTests.cs	Added tests to validate global string value reading.
src/native/managed/cdacreader/tests/ContractDescriptor/ContractDescriptorHelpers.cs	Added helper for JSON serialization of global strings.
src/native/managed/cdacreader/tests/ContractDescriptor/ContractDescriptorBuilder.cs	Extended builder API to include global strings.
src/native/managed/cdacreader/Microsoft.Diagnostics.DataContractReader/ContractDescriptorTarget.cs	Integrated global strings into target reading.
src/native/managed/cdacreader/Microsoft.Diagnostics.DataContractReader/ContractDescriptorParser.cs	Added global strings support in JSON serialization and diagnostics.
src/native/managed/cdacreader/Microsoft.Diagnostics.DataContractReader.Abstractions/Target.cs	Defined abstract TryReadGlobalString method.
src/coreclr/tools/cdac-build-tool/data-descriptor-blob.md	Updated blob specification to include GlobalStringSpec.
src/coreclr/tools/cdac-build-tool/ObjectFileScraper.cs	Modified header reading and parsing logic to handle global string specs.
src/coreclr/tools/cdac-build-tool/DataDescriptorModel.cs	Extended descriptor model to incorporate global strings.

Files not reviewed (4)

• src/coreclr/debug/runtimeinfo/datadescriptor.cpp: Language not supported
• src/coreclr/debug/runtimeinfo/datadescriptor.h: Language not supported
• src/coreclr/tools/cdac-build-tool/sample/sample.blob.c: Language not supported
• src/coreclr/tools/cdac-build-tool/sample/sample.data.h: Language not supported

[dotnet-policy-service]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

[davmason]

I don't like the algorithm of "try a number, if it fails it is a string." Since we own the spec we should be able to do better. Is there a reason we have to have the implicit string type and can't just use the explicit one?

[max-charlamb]

You mean the type of the json node or the optional string representing the type of the value?

[davmason]

I meant the optional string, could we have a string by itself be a number and only treat it as a string if we add the optional type

[max-charlamb]

Closing as this content was combined in #113899