Implementation of SOSDacApi GetMethodDescName for cDAC #106169

davidwrighton · 2024-08-09T00:31:55Z

Add a number of new MethodDesc contract definitions

Contract algorithm on RuntimeTypeSystem
`IsGenericMethodDefinition`
`GetGenericMethodInstantiation`
`GetMethodToken`
`IsArrayMethod`
`IsDynamicMethod`
`IsStoredSigMethodDesc`
`IsNoMetadataMethod`
`IsILStub`

Update cDAC compat asserts in cDAC to always be enabled by using a tls variable in mscordaccore

Implement GetMethodDescName on ISOSDacInterface in the cdacreader

Stub out an implementation of GetPath in the Loader contract used in a fallback after a fallback. This will need further work, but is included to make sure the code path isn't lost.

Fix the EcmaMetadataReader to be able to find blobs in the metadata

Add ability to read target data from a buffer held on the cdac side using the Target class. This was needed to handle signature containing a CorElementType.Internal.

And finally actually implement the name generation algorithm via a line for line port from the CoreCLR codebase.

Contributes to #99302

Add implementations for changes to RuntimeTypeSystem contract Add SOSDacInterface call into cDac for GetMethodTableName

- Move pointer to Module class - Replace use of SBuffer abstraction with a simple counted byte memory block Add metadata details to Loader contract Add Metadata helper api for use by contracts within the cDAC (and possibly clients of cDAC too)

1. It works now!

- Remove TypeHandleArray and MethodTableArray in favor of contract specific logic

…ime into cdac-methodtable-name

Co-Authored-By: David Wrighton <davidwr@microsoft.com>

mock the additional data and globals

- Add test suite for the DacStreams contract

dotnet-policy-service · 2024-08-09T00:32:34Z

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

lambdageek

First set of comments. Didn't look at Ecma or the formatter yet

docs/design/datacontracts/RuntimeTypeSystem.md

lambdageek · 2024-08-09T20:38:27Z

src/native/managed/cdacreader/src/Contracts/RuntimeTypeSystem_1.cs

+        {
+            get
+            {
+                int tokenRemainderBitCount = _target.ReadGlobal<byte>(Constants.Globals.MethodDescTokenRemainderBitCount);


Can we either store the token remainder bit count in the MethodDesc, or just pre-compose the token when creating the MethodDesc instance? I've been avoiding storing Target and contracts in data structures, so they're just dumb value holders, not fancy algorithms.

src/native/managed/cdacreader/src/Contracts/RuntimeTypeSystem_1.cs

docs/design/datacontracts/RuntimeTypeSystem.md

lambdageek

LGTM. modulo nits. And it would be really really nice if RuntimeTypeSystem_1.MethodDesc didn't hold on to Target

lambdageek · 2024-08-09T21:09:40Z

src/native/managed/cdacreader/src/Target.cs

@@ -5,6 +5,7 @@
 using System.Collections.Generic;
 using System.Diagnostics;
 using System.Diagnostics.CodeAnalysis;
+using System.Net;


nit: unused (presmably) using

1. Rename mcNDirect to mcPInvoke 2. Rename MethodDescClassification to MethodClassification 3. Remove mc prefix from all MethodClassification enum values 4. Move handling of various forms of MethodDescs to using an AsBlah method, and handle the flags in those methods, to make the actual contract methods somewhat simpler. 5. Compute the token eagerly on MethodDesc creation to avoid having to hold a pointer to the Target

elinor-fung · 2024-08-10T00:40:04Z

docs/design/datacontracts/RuntimeTypeSystem.md

+    // Return true if a MethodDesc represents a dynamically generated method, either an IL Stub dynamically
+    // generated by the runtime, or a MethodDesc that describes a method represented by the System.Reflection.Emit.DynamicMethod class
+    // A dynamic method is also a StoredSigMethodDesc
+    public virtual bool IsDynamicMethod(MethodDescHandle methodDesc, out ReadOnlySpan<byte> methodName);


Would it make sense to just make methodName a string instead of ReadOnlySpan<byte>, so the consumer doesn't have to know the encoding?

Not a bad idea. In general, I don't want to expose arrays to contract users, as its far to easy to mutate them, but strings are nice in that they are our only truly immutable type in the BCL, and work nicely for this sort of thing.

elinor-fung · 2024-08-10T00:53:52Z

docs/design/datacontracts/RuntimeTypeSystem.md

+
+    // Return true for a MethodDesc that describes a method represented by the System.Reflection.Emit.DynamicMethod class
+    // A LCG method is also a StoredSigMethodDesc
+    public virtual bool IsLCGMethod(MethodDescHandle methodDesc);


I know we have IsLCGMethod on the native MethodDesc, but is LCG the term we want to keep using going forwards? Would IsReflectionEmitMethod make more sense?

At least personally, LCG is not a term I use - I just think of it as reflection emit.

DynamicMethod is the public name of the LCG feature.

ReflectionEmit is more general. Some methods emitted using Reflection.Emit are dynamic methods, some are not.

So then would this make sense:

IsDynamicMethod -> IsDynamicallyGeneratedMethod

IsLCGMethod -> IsDynamicMethod

... whereas I think of Reflection.Emit as a thing that only applies to things that generate the full metadata and types which is also not completely accurate... The actual term in the BCL is that an LCGMethod maps to a method represented by the System.Reflection.Emit.DynamicMethod class, but calling it a DynamicMethod... might be extra special confusing, since the runtime has multiple meanings of what a DynamicMethodDesc represents, only 1 of which is a System.Reflection.Emit.DynamicMethod. (And of course LCG stands for Lightweight CodeGen, which is an internal codename that probably doesn't still need to be kept around.) I'd like to hear what @lambdageek, and @AaronRobinsonMSFT think on this, as I know I'm not objective here as I've worked on this stuff for FAR too long to see things reasonably. Possibly the right approach would be to call it DynamicMethod and sometime in .NET 10, rename the DynamicMethodDesc to something like RuntimeILMethodDesc.

I like the rename that elinor mentioned above at #106169 (comment).

rename the DynamicMethodDesc to something like RuntimeILMethodDesc.

I also agree with your suggestion above. I could also see GeneratedMethodDesc or ILEmitMethodDesc as options too.

I like IsLCGMethod -> IsDynamicMethod and DynamicMethodDesc ->ILEmitMethodDesc.

Not sure about IsDynamicMethod -> IsDynamicallyGeneratedMethod. Would just IsGeneratedILMethod be too broad?

DynamicMethodDesc ->ILEmitMethodDesc.

How about DynamicMethodDesc ->NoMetadataMethodDesc and IsDynamicMethod -> IsNoMetadata (existing property)?

Part of the codebase uses the NoMetadata name already:

runtime/src/coreclr/vm/method.hpp

Lines 626 to 630 in fa33edd

inline DWORD IsNoMetadata() const

{

LIMITED_METHOD_DAC_CONTRACT;

return (mcDynamic == GetClassification());

}

. Notice that MethodDesc::IsDynamicMethod and MethodDesc::IsNoMetadata have the same implementation.

The key property of the DynamicMethodDesc is that it has no ECMA-335 metadata, it has no metadata token, etc.

Dynamic IL generation is not the key property of DynamicMethodDesc. The regular ECMA-335 MethodDescs can have dynamically generated (IL) code too. For example, UnsafeAccessors have dynamically generated IL but they are regular MethodDescs.

I like @jkotas's idea here. Then the IsDynamicMethod api at the cdac level makes total sense, the existing DynamicMethodDesc translates to NoMetadataMethodDesc and gets a better name that more matches its utility, and we get rid of having both MethodDesc::IsNoMetadata and MethodDesc::IsDynamicMethod which are today exactly the same thing. While I'm at it, I'll rename mcDynamic to mcNoMetadata

I'm trending toward the idea of putting this rename in a separate PR. Opinions?

Offline discussion is to put together a separate PR for that. I'll just add a commit to update the cdac contract side naming to IsDynamicMethod, and the renaming of the underlying structures to be less confusing will be a separate PR that will probably miss .NET 9.

davidwrighton and others added 30 commits July 9, 2024 10:11

Progress towards GetMethodTableName

255da99

Move metadata reader into helpers

0671cd4

Add implementations for changes to RuntimeTypeSystem contract Add SOSDacInterface call into cDac for GetMethodTableName

Fix bugs found when trying to actually use this logic

d359ed9

1. It works now!

Update contract documentation

fc24cd4

Merge branch 'main' into cdac-methodtable-name

d93e98b

Feedback

fead409

Add support for the EEName DacStream

d2b36fc

- Refactor to expose TypeHandle exclusively from the contracts

8fdcc24

- Remove TypeHandleArray and MethodTableArray in favor of contract specific logic

Address concern around data structure for DynamicMetadata

30da32c

Merge branch 'cdac-methodtable-name' of github.com:davidwrighton/runt…

87f7003

…ime into cdac-methodtable-name

Fix build break

143cb86

Fix musl build issue

7284f83

Cherrypick RuntimeTypeSystem changes from dotnet#104759

2d5ec4f

Co-Authored-By: David Wrighton <davidwr@microsoft.com>

update tests

8e2dbca

start GetMethodDescDataImpl

e3964f9

WIP: managed GetMethodDescData skeleton

38d0a51

wip: MethodDesc

9d88f19

add MethodDescChunk

4a4c3a4

WIP: validating a MethodDesc

510a10f

checkpoint: MethodDesc validation

419cb11

update contract

1321aa9

fix RuntimeTypeSystem unit tests

dcc4540

mock the additional data and globals

update contract

c31bdcf

fix GetMethodDescChunkPointerMayThrow

7517e32

update tests

54ab23e

fixup rebase

27fcddc

Remove unnecessary usings

2a41206

- Transform magic numbers from DacStreams implementation into constants

dbe3cf4

- Add test suite for the DacStreams contract

Feedback

3a35f41

dotnet-issue-labeler bot added the area-Diagnostics-coreclr label Aug 9, 2024

dotnet-policy-service bot assigned davidwrighton Aug 9, 2024

davidwrighton mentioned this pull request Aug 9, 2024

[cdac] Implement !PrintException #99302

Open

21 tasks

Remove extra lines found in Loader_1.cs

c250bb8

lambdageek reviewed Aug 9, 2024

View reviewed changes

jkoritzinsky reviewed Aug 9, 2024

View reviewed changes

docs/design/datacontracts/RuntimeTypeSystem.md Outdated Show resolved Hide resolved

lambdageek approved these changes Aug 9, 2024

View reviewed changes

elinor-fung reviewed Aug 10, 2024

View reviewed changes

davidwrighton added 2 commits August 12, 2024 10:02

Adjust cdac naming to new model

bcf9fba

Merge branch 'main' into cdac-methoddescname

de846a5

build-analysis bot mentioned this pull request Aug 13, 2024

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

3 tasks

davidwrighton merged commit 272a83e into dotnet:main Aug 13, 2024
152 checks passed

lambdageek mentioned this pull request Aug 15, 2024

[feature/9.0-cdac-backports] Data descriptor changes for GetMethodDescName #106463

Closed

1 task

github-actions bot locked and limited conversation to collaborators Sep 14, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implementation of SOSDacApi GetMethodDescName for cDAC #106169

Implementation of SOSDacApi GetMethodDescName for cDAC #106169

davidwrighton commented Aug 9, 2024 •

edited

Loading

dotnet-policy-service bot commented Aug 9, 2024

lambdageek left a comment

lambdageek Aug 9, 2024

lambdageek left a comment

lambdageek Aug 9, 2024

elinor-fung Aug 10, 2024

davidwrighton Aug 10, 2024

elinor-fung Aug 10, 2024

jkotas Aug 10, 2024

elinor-fung Aug 10, 2024

davidwrighton Aug 10, 2024

AaronRobinsonMSFT Aug 10, 2024 •

edited

Loading

lambdageek Aug 10, 2024

jkotas Aug 10, 2024

davidwrighton Aug 12, 2024 •

edited

Loading

davidwrighton Aug 12, 2024

davidwrighton Aug 12, 2024

	inline DWORD IsNoMetadata() const
	{
	LIMITED_METHOD_DAC_CONTRACT;
	return (mcDynamic == GetClassification());
	}

Implementation of SOSDacApi GetMethodDescName for cDAC #106169

Implementation of SOSDacApi GetMethodDescName for cDAC #106169

Conversation

davidwrighton commented Aug 9, 2024 • edited Loading

dotnet-policy-service bot commented Aug 9, 2024

lambdageek left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lambdageek left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AaronRobinsonMSFT Aug 10, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davidwrighton Aug 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davidwrighton commented Aug 9, 2024 •

edited

Loading

AaronRobinsonMSFT Aug 10, 2024 •

edited

Loading

davidwrighton Aug 12, 2024 •

edited

Loading