Asyncify lists does not work correctly with dots

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

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?

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

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)Ú^

@juj

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)

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?

Fix WebAssembly#6047, WebAssembly#5271: Support one-line-one-function…

Support one-line-one-function file format for asyncify lists (WebAsse…

This still doesn't seem to be working (in Emscripten 4.0.16). I've specified assert_fail(char const*, ...) in my remove file, but it outputs this warning:

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

And the function isn't actually removed.

This still doesn't seem to be working (in Emscripten 4.0.16). I've specified assert_fail(char const*, ...) in my remove file, but it outputs this warning:
warning: Asyncify removelist contained a non-matching pattern: assert_fail(char const*,    ) (assert_fail\28char\20const*\2c\20\20\20\20\29)
And the function isn't actually removed.

I found that it's better to use wildcards like this:

assert_fail,assert_fail(*)*

This will match any variation of assert_fail

Also, I use whitelists and wrote a small script to generate them from the error stack. The algorithm for generating the whitelist is:

Start with an empty list.
Run the program, capture the error, and pass the stack trace to the script.
Update the whitelist and run the program again.
Repeat steps 2–3 until the program runs normally.

P.S. You need pass -sASSERTIONS=1 while generating lists

For some reason I thought I could only use wildcards at the beginning and end. Using one in the middle does work! But oddly asyncify-advise won't log anything (for other functions it logs [asyncify] vsnprintf is in the remove-list, ignore)

Maybe trying ASYNCIFY_IGNORE_INDIRECT and then ADDing back functions might be easier than working out which of the 315 "initial scan" functions I can remove. Thanks for the idea!

Yeah the support of wildcards is very limited

Navigation Menu

Repository navigation

Asyncify lists does not work correctly with dots #5271

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Asyncify lists does not work correctly with dots #5271

Description

Activity

kripken commented on Nov 17, 2022

kripken commented on Nov 17, 2022

caiiiycuk commented on Nov 17, 2022

kripken commented on Nov 17, 2022

juj commented on Nov 22, 2022

kripken commented on Nov 28, 2022

curiousdannii commented on Nov 7, 2025

caiiiycuk commented on Nov 7, 2025

caiiiycuk commented on Nov 7, 2025

curiousdannii commented on Nov 7, 2025

caiiiycuk commented on Nov 7, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions