Godot: Statically linked mono on Windows - external profiler doesn't work

[van800]

Godot version: 3.2

OS/device including version: Windows 10

Issue description:
When following steps in godotengine/godot#34382
JetBrains dotTrace or JetBrains Rider show "Unsupported Mono version"
It happens only on Windows with official Godot build, however with locally compiled Godot build with dynamically liked mono profiler works fine.

JetBrains engineers think that when mono is statically linked, its exports are not inherited.

JetBrains profiler dll loaded in Godot process is looking for mono api function and fails.

auto lib_handle = LoadLibrary("godot_exe_name");
auto func = GetProcAddress(lib_handle, "some_mono_function"); // this call fails

Example of the function: MONO_API MonoProfilerHandle mono_profiler_create (MonoProfiler *prof);

This happens only on Windows because mono on Windows works differently, as mono documentations says that for windows each function should be marked for export.
https://www.mono-project.com/docs/advanced/embedding/#windows-considerations

[van800]

May be related to godotengine/godot#29005

[neikeq]

Same goes with static linking when using msvc. The symbols are not exported. Is it actually possible to LoadLibrary an exe on Windows to do things like this?
The solution may be to just make the Godot editor dynamic link mono on Windows.

[MrZak-dev]

i just realized that the profiler is not working in Godot 3.2 Mono on windows , still there is no fix suggestions for this issue ?

[van800]

@MrZak-dev only known workaround is to compile godot locally.

[MrZak-dev]

maybe this has to be fixed in the coming version 3.2.1 ?

[MrZak-dev]

Fixed ! the profiler is working in Godot 3.2.1 Mono

[van800]

@MrZak-dev What do you mean? On locally compiled or official distribution?

[MrZak-dev]

@van800 it works for me on official distribution , but sometimes it doesn't and i had to restart the engine to get it working again .

[van800]

We are working on a solid fix, it requires changes in both Godot and JetBrains mono profiler.

[neikeq]

What changes are required in Godot?
Like I commented above, I think we may need to just link mono dynamically with the Godot editor on Windows, so that Rider can access the mono dll with its exported symbols. But maybe there's another way?

[van800]

If you link mono dynamically, it would solve the problem. Because profiler knows the exact name of the library, which contains mono api functions and those functions are already exported. This option still seems to be safer than the new one below, which we are trying to implement.

To make it work with statically linked mono:

1. On Godot side all mono api functions, required by the profiler, have to be exported again. Example: https://github.com/CRYTEK/CRYENGINE/compare/release...van800:mono-profiler#diff-6bc0fb18f4886d5b565152a0758f830eR1-R76
2. On profiler side we have to try all assemblies in the process and find the one with those exports.

[neikeq]

Hmm, not sure. Exporting all these symbols looks annoying to maintain over time. It may be better to just link mono dynamically.
Are all these symbols required? How often do new symbols tend to be added?

[evgn]

Searching mono library in a process is not a problem itself because official mono library name could be changed by Mono developers as well. The only significant problem here is inability to load mono exported functions from statically linked mono library. And as @neikeq noticed having fixed list of symbols on Godot side we should maintain it all the time. Even though adding new symbols seems uncommon we might need it to implement some new features. Thus it would be much better for us to work with dynamically linked mono.

[van800]

For sure, switching to dynamic linking is a preferable solution. @neikeq