Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asyncify lists use * as a wildcard, but function names can have * #2354

Open
kripken opened this issue Sep 24, 2019 · 6 comments

Comments

@kripken
Copy link
Member

@kripken kripken commented Sep 24, 2019

The names are full C++ names, so e.g. void foo(int *x) is a valid name. We treat that * as a wildcard currently, which may mean more things are matched than expected.

One solution is to use something other than * as a wildcard, but that would be annoying. Another option is to have separate lists for patterns and for specific names perhaps.

cc @Beuc

@Beuc

This comment has been minimized.

Copy link
Contributor

@Beuc Beuc commented Sep 24, 2019

In emscripten-core/emscripten#9381 (comment) I had asked whether globbing was OK, considering that's how Emterpreter worked.
Did something change? New user bug report?

@kripken

This comment has been minimized.

Copy link
Member Author

@kripken kripken commented Sep 24, 2019

No bug report, I just realized - kind of late :) - that in the Emterpreter we don't have * in function names (it's the C mangled name), but with the wasm backend we are forced to use the C++ human-readable name, which can have *.

So we do have a bug here that may eventually affect someone.

@Beuc

This comment has been minimized.

Copy link
Contributor

@Beuc Beuc commented Sep 25, 2019

OK, I assumed that potentially overmatching an overloaded function was considered an acceptable simplicity/coverage compromise.

Adding new command-line parameters for wildcard patterns would be fine by me, and make their use more explicit/clearer in Makefile-s.

@dschuff

This comment has been minimized.

Copy link
Member

@dschuff dschuff commented Sep 25, 2019

Backing up, this sounds like a case where we'd actually want to be using mangled names (e.g. anywhere you'd specify a list of functions in a command line or config file). What is forcing us to use demangled names?

@kripken

This comment has been minimized.

Copy link
Member Author

@kripken kripken commented Sep 25, 2019

When LLVM emits a names section, it emits human-readable names in there, so that's all we have in the wasm, the mangled names are gone...

I am not totally happy with that, but that's how it works atm. It is nice for naive stack traces, which show the human-readable name, but it does make things harder for tools (and stack traces could be fixed up, e.g., firefox demangles them). cc @sbc100 who I discussed this with.

@Beuc

This comment has been minimized.

Copy link
Contributor

@Beuc Beuc commented Oct 1, 2019

So what do we do? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.