Is there a technique to identify an API that has been trimmed in WASM?

[darenm]

I have an Uno application that runs fine in debug, but when compiled with Profile Guided AoT, it reports a runtime error, likely related to trimmed APIs. Is there a technique that can be used to identify what API(s) are being trimmed and how to update LinkerConfig.xml appropriately?

[jeromelaban]

To troubleshoot which API is being called you can use the following log configuration:

https://github.com/unoplatform/Uno.Wasm.Bootstrap/blob/9ccb4790e7c766e92b04ee3696fadef1a995bef9/src/Uno.Wasm.StaticLinking.Aot.Net5/Uno.Wasm.StaticLinking.Aot.Net5.csproj#L48-L52

It may give you a hint into what area is causing the issue, but it's generally not linker related, but rather AOT compiler related at the boundary between interpreted and AOTed code. Once you find what it is, we may be able to hint the AOT compiler.

[jeromelaban]

Sometimes __Internal is not working properly, can you try with __Native instead?

[darenm]

Where is that configured?

[jeromelaban]

Do you have any piece of code using __Internal in your codebase? If may be coming from something like this: [DllImport("__Internal")].

[darenm]

No explicit reference to "__Internal" in the code base. There are a few uses of DllImport. Running with the additional logging in Debug shows some additional resolution:

[MONO] DllImport attempting to load: 'pdf'.
[MONO] DllImport error loading library '__Internal': ''.
[MONO] Native library found via __Internal.
[MONO] DllImport error loading library '__Internal': ''.
[MONO] Native library found via __Internal.
[MONO] Native library found via filesystem probing: 'pdf'.
[MONO] DllImport searching in: 'pdf' ('pdf').
[MONO] Searching for 'initContext'.

The pdf assembly is a bitcode library that was loaded successfully in the UWP version of the application. Are there alternative build switches required for the WinUI version? The bitcode library is loaded and executes correctly when the app is built in Debug, etc.

[darenm]

Looks like the following code is being executed - but now to find where the __Internal is coming from...:

https://github.com/dotnet/runtime/blob/dbe6447aa29b14150b7c6dd43072cc75f0cdf013/src/mono/mono/metadata/native-library.c#L778

static MonoDl *
netcore_lookup_native_library (MonoAssemblyLoadContext *alc, MonoImage *image, const char *scope, guint32 flags)
{
	MonoDl *module = NULL;
	MonoDl *cached;
	MonoAssembly *assembly = mono_image_get_assembly (image);
	char *error_msg = NULL;

	MONO_REQ_GC_UNSAFE_MODE;

	mono_trace (G_LOG_LEVEL_DEBUG, MONO_TRACE_DLLIMPORT, "DllImport attempting to load: '%s'.", scope);

	// We allow a special name to dlopen from the running process namespace, which is not present in CoreCLR
	if (strcmp (scope, "__Internal") == 0) {
		if (!internal_module)
			internal_module = mono_dl_open_self (&error_msg);
		module = internal_module;

		if (!module) {
			mono_trace (G_LOG_LEVEL_INFO, MONO_TRACE_DLLIMPORT, "DllImport error loading library '__Internal': '%s'.", error_msg);
			g_free (error_msg);
		}

		mono_trace (G_LOG_LEVEL_DEBUG, MONO_TRACE_DLLIMPORT, "Native library found via __Internal: '%s'.", scope);

		return module;
	}

[darenm]

After working with @jeromelaban , we were able to determine the issue was related to a SkiaSharp API - specifically, a PNG codec was not available after AOT compilation, but was available in debug. Fortunately, I was able to implement a workaround.

During the diagnostics, we enabled EMCC Profiling as detailed here: Profiling WebAssembly applications.

// _loResImage.ImageData is a byte[] containing a PNG

// Failing code
var loResStream = new MemoryStream(_loResImage.ImageData);
// The Decode method had an internal error unable to run the PNG codec
var loResBitmap = SKBitmap.Decode(loResStream);

// Alternate code that runs without error
var loResSkImage = SKImage.FromEncodedData(_loResImage.ImageData);
var loResBitmap = SKBitmap.FromImage(_loResSkImage);