[wasm] Use g_printerr to emit errors in mini-wasm.c, so they show up wit…

[radical]

…h traces in the js console.

With just printf, you would see the error as:

ThreadPool Callback threw an unhandled exception of type System.TypeInitializationException

.. but with g_error, you get:

You don't get the message string itself, but that can be found by looking at the source line. Or you can build the runtime with /p:MonoEnableAssertMessages=true.

But you do get the stack trace for that error!

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

…h traces in the js console.

With just printf, you would see the error as:

ThreadPool Callback threw an unhandled exception of type System.TypeInitializationException

.. but with g_error, you get:

You don't get the message string itself, but that can be found by looking at the source line. Or you can build the runtime with /p:MonoEnableAssertMessages=true.

But you do get the stack trace for that error!

Author:	radical
Assignees:	-
Labels:	arch-wasm
Milestone:	-

[lewing]

Nice, stack is more useful than a printf.

• fix g_assert to print a stack?
• do something intltool-like and start moving strings to a table we can link in or out at WasmNativeBuild time?

[lambdageek]

Is the intention here to turn a benign error into a fatal one? g_error aborts the process.

[lewing]

@lambdageek makes a (very) good point, please use g_printerr like #49828

[radical]

Nice, stack is more useful than a printf.

• fix g_assert to print a stack?

It gets logged with the stack trace, I confirmed.

• do something intltool-like and start moving strings to a table we can link in or out at WasmNativeBuild time?

#49888