Asyncify lists does not work correctly with dots

[caiiiycuk]

Hi. I am using asyncify for jsdos project. And I found that ... is not handled correctly, for example I have function:

Program::WriteOut(char const*, ...)

When I compile I have warning:

warning: Asyncify onlylist contained a non-matching pattern: Program::WriteOut(char const*,    ) (Program::WriteOut\28char\20const*\2c\20\20\20\20\29)

As you can see dots are replaced with spaces:

expected (from wasm dis): Program::WriteOut\28char\20const*\2c\20...\29
actual                  : Program::WriteOut\28char\20const*\2c\20\20\20\20\29

[kripken]

Hmm, that could be a problem in wasm-ld where it demangles names into the names section, or it could be a problem in binaryen where it reads it. Can you look in the names section in the wasm binary (before binaryen runs) and see what appears there?

[kripken]

(I mean, to look with a hex editor - wasm-dis may be too late, if the bug is in binaryen parsing.)

[caiiiycuk]

I have this in wdosbox-x.wasm:

F#Program::WriteOut(char const*, ...)Ø^F+Program::WriteOut(char const*, char const*)Ù^F.Program::WriteOut_NoParsing(char const*, bool)Ú^

[kripken]

Looks correct, thanks... ok, I dug into this now since it's clear it's either an emscripten or a binaryen issue. Turns out it's on the emscripten side,

emscripten-core/emscripten#13477

The function unmangle_symbols_from_cmdline replaces . with spaces,

https://github.com/emscripten-core/emscripten/blob/c215ec6ad3ded63c7e50cf818006ad1cac469b4a/emcc.py#L804-L806

It looks like . is part of the escaping approach there, but the problem is that . is also a necessary character sometimes, with things like ... that appear in signatures.

cc @juj - what do you think the best solution is? One idea might be to not run unmangle_symbols_from_cmdline if the input arrives from a response file. Then at least response files would be a way to know exactly what you are getting. But maybe the escaping can be tweaked?

[juj]

cc @juj - what do you think the best solution is? One idea might be to not run unmangle_symbols_from_cmdline if the input arrives from a response file. Then at least response files would be a way to know exactly what you are getting. But maybe the escaping can be tweaked?

Ouch, ellipsis never occurred to me, I thought I was taking three characters that were all never used in the LLVM name mangling.

Maybe it would be good idea not to unmangle if the input does come from a response file. That would lose the kind of "interchangeability", but given that the problem is a bit exotic shell expansion in the first place, maybe that would be ok.

Another way might be to look for another character than '.' to replace with a space, e.g. does - ever appear in a symbol name since it is an operator? Though that might become awkward, since it is a breaking change for existing users who might rely on that mangling. (maybe such users are very rare though)

[kripken]

Good point about interchangeability... yeah, special behavior for response files seems risky.

A breaking change might be an option. I hope it would affect few people while it unbreaks this.

Another option might be to special-case ..., that is to not unmangle a sequence of three dots. Or are there cases where three dots are needed in escaped form - I think no, since that would mean three spaces?