Fix #24982: emsymbolizer failed to parse symbol map from C++ project

[LanderlYoung]

1. fix symbol map line parse
2. unescape ascii code
3. update tests: test/runner "other.test_emsymbolizer*"

This PR fixes #24982

[dschuff]

Thanks!

[kripken]

lgtm otherwise

[sbc100]

Is there some reason we cannot or should not just update the symbol map to avoid this mangling in the first place.

What is the source of the mangling in the first place? What style of mangling is std::out_of_range::~out_of_range\28\29 ?

[dschuff]

I don't know what kind of mangling that is; it doesn't exactly match others that I'm familiar with.
My assumption was that there are users that are depending on the contents of the symbol map. and would have some kind of workflow that would be broken if we were to change it. Maybe I'm wrong and we could just do that. Or, maybe it's ess of a breaking change to remove the special mangling than to go to a fully-C++-mangled state, since presumably users who depend on the current format would have their own demangling, so if we just stopped adding the mangling, maybe they wouldn't be broken?

[sbc100]

I don't know what kind of mangling that is; it doesn't exactly match others that I'm familiar with. My assumption was that there are users that are depending on the contents of the symbol map. and would have some kind of workflow that would be broken if we were to change it. Maybe I'm wrong and we could just do that. Or, maybe it's ess of a breaking change to remove the special mangling than to go to a fully-C++-mangled state, since presumably users who depend on the current format would have their own demangling, so if we just stopped adding the mangling, maybe they wouldn't be broken?

I'd be tempted to make that change to the symbol map to include fully demanged symbols. @kripken do you remember why we have these strange escape codes in the map file?

[kripken]

I'm not sure. But isn't the symbol map just copying the name section? It should contain whatever is there iirc.

[sbc100]

So maybe the issue is that the name section is broken?

[sbc100]

So maybe the issue is that the name section is broken?

The name sections is fine. The problem seems to stem from the wasm-opt --print-function-map command.. I guess binaryen doesn't like those symbols.

I think we should file a binaryen bug, or maybe just avoid binaryen for this purpose (since we don't need to run process the whole wasm file, only the name section.

[kripken]

@sbc100 do you want this PR to wait until we figure that out, or can this land?

[sbc100]

@sbc100 do you want this PR to wait until we figure that out, or can this land?

I don't think we we should land this since it would only act to further lock in the strange escaping behavior

[sbc100]

I think we should go with #25053 instead

[kripken]

Oh, I think the first part of this PR is still important though:

fix symbol map line parse

That handles splitting when the line contains :: as a separator.

We can refocus this PR on just that?

[sbc100]

Oh, I think the first part of this PR is still important though:

fix symbol map line parse

That handles splitting when the line contains :: as a separator.

We can refocus this PR on just that?

Ah, yes that could make sense.

[LanderlYoung]

Thanks guys! The name escape part has been reverted. Please review 🌹

[dschuff]

Looks good overall, just a couple of nits on the test.

[LanderlYoung]

Some other.test_codesize* tests seemed to fail, but I didn't find a relation with this code change.

[dschuff]

If you merge the PR to the tip of the main branch, the code size test failures should go away. And you'll have to do that anyway, since you have a conflict.

[sbc100]

Thanks for you patience on this PR. LGTM with one final comment!

[dschuff]

browser test failures are unrelated, I'll go ahead and merge this. Thanks!