diff options
| author | Jay Krell <jay.krell@cornell.edu> | 2018-10-23 00:03:05 +0300 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2018-10-23 00:03:05 +0300 |
| commit | 3c74df566776f468366d96dd164dd1a6b3d780cc (patch) | |
| tree | e3e7d295f8b93a61d1bafbbda6007d69952d2a53 /msvc/libmonoruntime-common.targets.filters | |
| parent | f2d67cd299e7730819f6838b77de8a061621cce1 (diff) | |
[coop] Transition all functions in object.h to MONO_RT_EXTERNAL_ONLY (#11188)
In general this is achieved by renaming mono_foo to mono_foo_internal,
and mono_foo_bar calls mono_foo_bar_internal, possibly adding a GC mode change
to mono_foo_bar and removing from mono_foo_bar_internal.
We can also consider other names like m_foo_bar, mi_foo_bar, m.foo_bar, m->foo_bar, m::foo_bar, using mi = mono_internal; mi::foo, foo.bar(), etc.
* [test] Report dlsym failure with an assertion failure and give the symbol.
* Compilation of external-only.c/.o needs special care.
Because it is dead code, except for exports, the linker does not necessarily eagerly look into it (.o within .a), and export anything. This is the usual behavior of Windows linker. Unix linker I guess it varies between programs and shared libraries, but it was observed and broke a test, and a small case was constructed to demonstrate the behavior (i.e. where the dlsym assert is added), even though I assumed the opposite -- so must be program vs. sharedlibrary.
Therefore, we `#include external-only.c` in object.c.
Longer term we should probably use Windows .def files and their Unix equivalent, and/or be sure to list external-only.o directly on the link command line, instead of burying it in a static library.
.def files were used in the past and have other advantages/differences.
Other than guaranteeably reaching into .a/.lib files to find exports, they also export on NT/x86 as plain "mono_foo" instead of "_mono_foo", easing portability of LoadLibrary / GetProcAddress.
The loss of the x86 C name mangling *could* be viewed as a loss, of a tiny amount of safety.
They also make declspec(dllimport) and declspec(dllexport) both pointless, at least for C functions -- dllimport remains significant for data and C++ (no need to list mangled names in .def file), and to microoptimize one instruction out of some calls on non-LTCG builds.
Diffstat (limited to 'msvc/libmonoruntime-common.targets.filters')
| -rw-r--r-- | msvc/libmonoruntime-common.targets.filters | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/msvc/libmonoruntime-common.targets.filters b/msvc/libmonoruntime-common.targets.filters index 5617d037984..0e81fb9c4ca 100644 --- a/msvc/libmonoruntime-common.targets.filters +++ b/msvc/libmonoruntime-common.targets.filters @@ -100,6 +100,12 @@ <ClInclude Include="$(MonoSourceLocation)\mono\metadata\exception-internals.h"> <Filter>Header Files$(MonoRuntimeFilterSubFolder)\common</Filter> </ClInclude> + <ClInclude Include="$(MonoSourceLocation)\mono\metadata\external-only.c"> + <Filter>Header Files$(MonoRuntimeFilterSubFolder)\common</Filter> + </ClInclude> + <ClInclude Include="$(MonoSourceLocation)\mono\metadata\external-only.h"> + <Filter>Header Files$(MonoRuntimeFilterSubFolder)\common</Filter> + </ClInclude> <ClCompile Include="$(MonoSourceLocation)\mono\metadata\w32file.c"> <Filter>Source Files$(MonoRuntimeFilterSubFolder)\common</Filter> </ClCompile> |