Use the build_id (or something else) to split name section

[binji]

Similar to https://github.com/WebAssembly/tool-conventions/issues/133, it would be nice to be able to serve a wasm file without a name section, but have it associated with a wasm file that has a name section. In particular this would be useful for developers profiling or getting stack traces from a wasm file in production.

I'm not sure if build_id is the right mechanism for this, or perhaps a custom section with a private URL. Any thoughts?

[dschuff]

My initial thought is that this would be a great fit for a build ID. One of the main use cases for a build ID is associating a stripped file with one that still has all the debug info (or with a separate debug-info file). We've generally thought of a name section as just sort of a special case of debug info, so I would think the build ID would fit with that as well. I guess it does mean that there's no explicit URL, so that it's the responsibility of the system that manages those artifacts and symbolizes the stack traces, etc to track that.

[binji]

Hm, so I can see this working for an offline tool, but how do you think we could make this work for a developer loading the wasm file from the prod server on their own machine? It feels like we'd need some kind of browser integration to make that work.

[dschuff]

Ah, I see what you mean. Currently we have sourceMappingURL that serves that purpose for source maps (I think this works in Chrome?) and IIRC Chrome's DWARF extension uses a manual configuration to remap path names in debug info. Currently the name section is a bit more special, since it's understood more directly by V8 and its information integrated more directly into devtools (e.g. for stack traces and profiling as you said). But in principle it seems like a good idea. I wonder if @pfaffe could say more about how easy that would be to implement. (Does sourceMappingURL work without the extension? It seems pretty similar)

[dschuff]

Actually it occured to me that source maps also have the names list, which could be used to provide function names as well. Currently IIRC we don't use that with wasm, but it could potentially be made to work (e.g. create a mapping that covers the bytes of the function header, with a reference to the name entry).

[emartinfigma]

I tinkered a bit with trying to generate a source map with names entries to provide function names, but at least in my limited experimenting I couldn't get Chrome to understand it.

Concretely I generated a source map that had this data:

// mappings are:
//  [offset, filename, line, col, name]
// where filename is an index into the source array
// and name is index into the names array
const mappings = [
  [0,0,0,0,0], 
  [0x2aa,1,0,0,0],
];

const map = {
    version: '3',
    sources: ['abc', 'def'],
    names: ['ghi', 'jkl'],
    mappings: ... the above in source map encoding ...
};

And then I generated a stack trace. The Chrome debugger showed that I had successfully mapped two different functions to two different file names (abc and def in the above), which means my mappings were being applied to the WASM functions, but I didn't see any function names in the backtrace.

However, I may have gotten the source map spec totally wrong here! It's not at all clear to me how the names array is supposed to actually map to a function name.

[emartinfigma]

CC @concavelenz (hi John, long time no see!) just in case he had some advice. :)

[dschuff]

Yes; to be clear, I don't think that Chrome understands the name fields in source maps today. But I expect it could be made to work.

[pfaffe]

sourceMappingURL works without the DWARF extension, that's a separate mechanism in DevTools.

Yes; to be clear, I don't think that Chrome understands the name fields in source maps today. But I expect it could be made to work.

DevTools understands sourcemaps, including the names, but V8 does not. V8 makes the exception object including its backtrace, but it does not consider sourcemaps. That's why DevTools shows you names on the callstack but the backtrace doesn't.

If the use case is to look at production profiles or stacktraces, wouldn't it be easier to have whatever tool displays these symbolize them on the fly? That would get us back into the "offline tool" waters where build-ids are easy to use.