Skip to content
This repository has been archived by the owner on Nov 1, 2020. It is now read-only.

[CppCodeGen] Enable reflection #2035

Closed
jkotas opened this issue Oct 16, 2016 · 4 comments
Closed

[CppCodeGen] Enable reflection #2035

jkotas opened this issue Oct 16, 2016 · 4 comments

Comments

@jkotas
Copy link
Member

jkotas commented Oct 16, 2016

Remove reflection block for CppCodeGen and make the simple reflection test pass.

@rollsch
Copy link

rollsch commented May 1, 2017

Do you guys have anything in mind with how you will achieve this? Will you effectively build some sort of metadata cache?

I am very interested in this.

@MichalStrehovsky
Copy link
Member

This would reuse the same scheme we already have for the RyuJIT codegen path:

  • The compiler generates a blob of bytes that describes the metadata (namespaces, types, their members, their custom attributes, method parameters, etc.). The data is generated as a byte array in the ComputeMetadata method.
  • The metadata gets embedded as a data blob into the executable image. This is achieved by adding the blob to a "ready to run header". Ready to run header is a well known data structure that can be located by the code in the framework at runtime.
  • The ready to run header along with the blobs it refers to is emitted into the final executable.
  • At runtime, pointer to the byte array is located using the RhFindBlob API, and a parser is constructed over the array, to be used by the reflection stack.

The first step in implementing this will be to come up with a scheme where the ready to run header can be emitted into the generated code, and the byte array with the metadata can be referenced by the CppCodegen generated code. This will be something similar to what we do for the EEType data structure.

That should be enough to get Type.GetType("System.Object, System.Private.CoreLib") working with CppCodegen.

More work will be needed to emit what we call "mapping tables" that map runtime artifacts (method entrypoints, static bases for fields, runtime type structures, etc.) to the records described in the byte array. The mapping tables are necessary to get the more interesting APIs working, such as Object.GetType(), MethodInfo.Invoke(), FieldInfo.GetValue, etc. But that's a next step. The byte array with the metadata is a necessary prerequisite.

@rollsch
Copy link

rollsch commented Mar 7, 2018

Just wondering how this was progressing. Is it realistically ever likely to produce a working exe from a wpf project?

@MichalStrehovsky
Copy link
Member

This was fixed in #6700.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants