Lokad / ILPack

Serialize .NET Core assemblies

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unable to translate FieldBuilders with no declaring type

masonwheeler opened this issue · comments

ModuleBuilder.DefineInitializedData creates a FieldBuilder holding a const blob of data. This FieldBuilder is created without a DeclaringType, and as DeclaringType is a read-only property, there is no way to set a value for it.

Lokad.ILPack.Metadata.AssemblyMetadata.GetFieldHandle assumes that every FieldInfo will have a non-null DeclaringType, and throws NRE when it runs across a field defined by DefineInitializedData.

Thanks @masonwheeler Don't hesitate to create a PR on this.

I'm not sure how to handle this one. I've got a PR in the works for the other one I submitted last night, but this one is trickier. I'll look into it a bit more...

I found a few different problems here.

  1. AssemblyGenerator.CreateModules is calling CreateFields before it calls CreateTypes.
  2. It's calling CreateFields without specifying AllFields as binding flags.
  3. There's an order of operations problem. Types need to be defined before fields of those types. Fields need to be defined before method bodies reference them. But method bodies are processed inside the CreateTypes call.
  4. DefineInitializedData stores const data in the .sdata section of the PE file. It's not immediately clear how to retrieve this data and store it the same way with System.Reflection.Metadata.Ecma355.

The first 3 points are easy enough to work around with a bit of refactoring, but I'd appreciate some help on 4 if anyone knows this better than I do?

For point 4, it looks like this is already working, as part of the field creation process. So I have a working patch, but I'm not sure how to write tests for it.

I ran across this bug while working with code involving array literals. But the existing ILPack test corpus has test cases covering array literals, which suggests that C# does it in a different way and there's no way to trigger this by adding an example to the C# test class.

@vermorel These features (global data and global functions) are not usable from C#/VB.NET/F# languages. I suggest canceling (or at least postponing) it for now.

OK to postpone indefinitely, especially if it appears there is no demand for this feature.