How to preserve function names in wasm release builds

I have been experimenting with the WebAssembly backend for the past few weeks. Everything works great, except a few. One thing in particular is that when build in release mode (either ReleaseSmall or ReleaseFast), non-exported functions loses its name in the final .wasm file.

As it’s many times vital to have the function names to understand profiling reports, we really like to have the function names available. We have tried to mark the important functions both noinline and pub, but having no luck. Only functions marked as export will have their name preserved in the final assembly.

Is there a way around it? That is, is there a way to preserve function names in the compiled wasm file without exporting the functions in release builds?

I don’t know, but one workaround could be to create a mapping from functionpointer addresses to strings, basically creating a way for you to recover the original name from a functionpointer.

How/where are you looking at the names, could you use code to recover the name in such a way?

Are the names gone in ReleaseSafe too? If not, my guess would be that at least a custom build of zig could switch that feature on, so that the names remain, but I don’t know if there is already some kind of commandline flag/option.

1 Like

I’m profiling with Chrome’s Devtools, which displays function names correctly for Debug build but not for release builds.

As we mostly want the function names showing up in Devtools (and other debuggers/profilers), a mapping between function pointers to strings won’t directly help. Although we could definitely build some extra tooling to postprocess the compiled wasm but that is just… very involved…

I just tried ReleaseSafe (didn’t thought about it :sweat_smile:) and indeed the function names are preserved! It’s definitely one step better but different from the binaries you get with ReleaseSmall/Fast, which are the most interesting target for profiling… We might stick with ReleaseSafe for now until another solution comes around.

1 Like

Actually if Zig’s wasm target ever supports source map, then this problem would be gone, with many other benefits in debugging. But I guess that’s just a big ask for now :sweat_smile:.

1 Like