Provide API get ClrType directly by MT & CMT for Desktop flavor

[zvirja]

Extend ClrHeap API and provide with method to get ClrType by MT& CMT pair, without need in object address.

That will allow to store information about types and later re-use it after app restart.

This issue complements the #12.

[leculver]

I've begun work on this, not completed. You can see the work in progress with recent commits. Keep in mind that method tables are per type and per app domain. A single clrtype type may have multiple methodtables associated with it. Note that I have named the relevant properties "TypeHandle" as this is more accurate across all versions of clr.

More work coming this week includes getting the app domain from methodtables, mt from object address, eeclass support and so on.

If you have feedback about the design and direction please feel free to comment on the checkin or issues here.

[zvirja]

As long as you're implementing new features, I'm more and more confident I doesn't understand how CLR is designed internally at all :)

Everything looks OK to me, given that type could have multiple MTs. Is this correct for modules that are loaded to the shared domains only? I thought that each AppDomain has its own copy of modules and inner types.

The only note here is whether you keep generics in mind and how they are implemented. For instance, presence of the "canonical" types could lead to the shared EEClass for multiple MTs, etc.

[leculver]

That is one of the main reasons that I have been hesitant to implement MethodTable support in ClrMD. ClrMD purposefully attempts to hide a lot of the messy implementation details from you. Literally the only reason I decided to implement them is so that it can interop with other tools (and to give missing functionality other tools can do).

Keep in mind that there will be a lot of weird corner cases and stuff you have to work around when dealing with the raw implementation details of CLR (such as MethodTables).

Lastly, please also keep in mind that the underlying dac API does not fully support generics. I will be able to at least provide the same level of generics support that it does, but ClrMD will not be able to fully represent all possible generics unless I make corresponding fixes to the underlying Dac API...which is difficult and unlikely.

[lasherer]

The solution of some problems are in the gore details though. So, making at available at least on demand can help a lot of people without impacting those who still cannot find any use yet 😊

Sent from my Windows Phone

---

From: Lee Culvermailto:notifications@github.com
Sent: ‎9/‎28/‎2015 6:13 PM
To: Microsoft/clrmdmailto:clrmd@noreply.github.com
Subject: Re: [clrmd] Provide API get ClrType directly by MT & CMT for Desktop flavor (#13)

That is one of the main reasons that I have been hesitant to implement MethodTable support in ClrMD. ClrMD purposefully attempts to hide a lot of the messy implementation details from you. Literally the only reason I decided to implement them is so that it can interop with other tools (and to give missing functionality other tools can do).

Keep in mind that there will be a lot of weird corner cases and stuff you have to work around when dealing with the raw implementation details of CLR (such as MethodTables).

Lastly, please also keep in mind that the underlying dac API does not fully support generics. I will be able to at least provide the same level of generics support that it does, but ClrMD will not be able to fully represent all possible generics unless I make corresponding fixes to the underlying Dac API...which is difficult and unlikely.

---

Reply to this email directly or view it on GitHub:
#13 (comment)

[leculver]

Added the basic support for this now. Next up will be methoddescs and EEClass support, but I'm using the other issue to track that. As such I'm closing this issue as completed.