-
Notifications
You must be signed in to change notification settings - Fork 5k
Support using function pointers with PersistedAssemblyBuilder
#115015
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Tagging subscribers to this area: @dotnet/area-system-reflection |
Mh, actually I just saw #75347 and #75348, currently in the .NET 10 milestone, so it seems a whole lot of work around function pointers is already planned and being done? Would those two also cover this scenario? Not sure I'm seeing an API to create a new function pointer type you can then use to define a field in a new type. Also, are those items likely to make .NET 10? 🤔 |
Function pointers support in Reflection.Emit is not implemented as you can see from the issues that you have linked.
Milestone field set to .NET 10 does not mean that the work is planned/committed for .NET 10. |
I see. Looking at that issue, it seems that emitting |
Reflection.Emit in .NET Framework is coupled with .NET Framework mscorlib that the process is running on. You would have hard time emitting references to things that do not exist in .NET Framework mscorlib. |
Alright, let's scratch that then. I'm out of ideas 😆 |
Currently we have not added support for obtaining or declaring a new function pointer-based field, property or parameter. However, emit does support calli against a native int \ intptr value. So a workaround is to use intptr-based fields, etc. having a "partner-impact" status does increase the priority, so we'll see if we can put a plan together v10. cc @ericstj. |
I considered that, however we can't do that as it'd break ILC folding for vtables.
Yup, to clarify I only added that tag for context, not to necessarily affect priority.
I think we're good, no need to prioritize this. We ended up going with https://github.com/Washi1337/AsmResolver, which seems extremely flexible and covers everything we need for both reading metadata and emitting the final assembly. We've already had a bunch of asks for the runtime team for things we'd like to get for CsWinRT 3.0 (see #114179), so I want to be respectful of everyone's time and make sure to only ask to prioritize things that are either actually blocking us, or that would be problematic for us if they missed the .NET 10 release. This is not one of them, now that we're going with another library to handle our IL analysis and generation. So just to clarify, feel free to not consider us (CsWinRT) with respect to planning for any of the new reflection work 🙂 (I also did not add this issue to that epic, to make sure it was clear it doesn't have to be considered in that same bucket) Thanks again to both of you! |
Thanks for the update. I think it makes sense to mark this as a duplicate of #111003 which we hope to get done for v10. |
Note
Follow up from #106216
Not exactly sure how to structure this issue, as it's technically some kind of API proposal, but I also don't have an exact API shape yet. The general issue is that it doesn't seem to be possible to use function pointers when using
PersistedAssemblyBuilder
to create a .dll (though this seems to be a more general issue with reflection in general too). Suppose you want to define a type like this:There is no way to get or create a
Type
instance that you can pass toTypeBuilder.DefineField
to define that field.Presumably we'd need some kind of API on
ModuleBuilder
(?) to synthesize aType
for a given function pointer.This is impacting CsWinRT 3.0 in the sense that we realized we can't generate all the interop code we need in the sidecar .dll via
PersistedAssemblyBuilder
, because of this limitation (we can't emit the function pointer types, nor thecalli
invocations for them). We're thinking we could take a dependency on Roslyn and generate a separate .dll with just the vtable types, from C# sources, and reference that from the real sidecar .dll, built withPersistedAssemblyBuilder
. It seems that if you do this, you can actually use function pointer types, as long as you "get them from somewhere", rather than synthesizing them yourself. Of course, this adds complexity and we'd rather just usePersistedAssemblyBuilder
for everything, and just end up with a single sidecar .dll, instead of two.This seems related to #111003, so possibly
PersistedAssemblyBuilder
also has other bugs that would still make it break with function pointers?cc. @jkotas do you have any thoughts on this? From our side in CsWinRT, some not necessarily complete feature would also be fine, as long as we wouldn't be blocked from shipping (perhaps just fixing #111003 plus us using the two .dll-s would be enough for now?). I can also help put together some minimal examples of the kind of code we'd need to generate, so we could validate that things work enough for us in the meantime.
The text was updated successfully, but these errors were encountered: