[Mono-dev] [PATCH] Make mono_dl_register_library into a fallback

Michael Hutchinson m.j.hutchinson at gmail.com
Fri Jul 2 12:38:34 EDT 2010


On Fri, Jul 2, 2010 at 6:18 AM, Paolo Molaro <lupus at ximian.com> wrote:
> On 07/01/10 Michael Hutchinson wrote:
>> The mono_dl_register_library function can currently be used to
>> register P/Invoke mappings for platforms that do not have a dynamic
>> linker. The attached patch makes it also function as a fallback when
>> the system's dynamic linker cannot resolve the library, so that it is
>> always available to embedders.
>>
>> I'll also need to restore mono/utils/mono-embed.h to the public
>> headers in the autotools build (but this patch was created using MSVC
>> on Windows).
>>
>> OK to commit to trunk?
>
> This interface is not suitable as a fallback mechanism, it would be too
> cumbersome to use and it's probably not ideal even for its intended
> purpose. What about a callback registration system instead?

The intended purpose, AFAIK, is to expose statically linked libraries
to P/Invoke. That's what I'm using it for, and it's very
straightforward to use this way. I have a trivial C# tool that
reflects over the library with the P/Invokes and dumps the mappings to
source files.

My patch isn't intended to provide a generic dynamic linker fallback.
It's meant to provide an easy way to P/Invoke statically linked
libraries for all embedders, not just those on platforms without
dynamic linkers.

> It is more flexible as a fallback since it doesn't require to register
> upfront all the possible names and load the all functions at startup.
> It's likely better also for the original purpose when, for example,
> even if dynamic linking is not possible it is possible to lookup a
> symbol at runtime.
> It opens up the possibility of also generating the code at runtime
> (for redirecting some win32 p/invokes to winforms for example, or other
> tricks).
>
> Something along these lines:
>
> typedef void* (*MonoDlFallbackLoad) (const char *name, int flags, char **err, void *user_data);
> typedef void* (*MonoDlFallbackSymbol) (void *handle, const char *name, char **err, void *user_data);
> typedef void* (*MonoDlFallbackClose) (void *handle, void *user_data);
>
> void mono_dl_register_fallback (MonoDlFallbackLoad load_func, MonoDlFallbackSymbol symbol_func,
>                MonoDlFallbackClose close_func, void *user_data);
>
> The old interface could be easily implemented on top of this new one (though we
> likely could drop it as well).

That's certainly more flexible, but I'm not convinced it's necessary
at this time without concrete use cases. If we're going to include the
old interface anyway - else we make embedders responsible for
reimplementing its functionality - then why not go this path for now,
and reimplement it on top of the callbacks later?

The tricks you mention could be much more useful if callbacks could
intercept lookups for individual symbols, rather than acting as a
fallback for handling whole libraries. But this would require much
more substantial changes to the dynamic linker code.

-- 
Michael Hutchinson
http://mjhutchinson.com


More information about the Mono-devel-list mailing list