[Question] ASM.js mangled names

[lbittner-pdftron]

Hello!

I created a fork of this project to update Binaryen so I can produce a proper ASM.js file, which is working okay.

I've noticed that the exported function names are all mangled (which i'm assuming the WASM file does as well - except the loader handles it).

Is the loader supposed to be able to handle ASM modules as well? Ive tried running the ASM module through loader.demangle but it doesn't seem to do anything.

Any help is appreciated. Thanks!

[jtenner]

Did you use the --debug flag?

[lbittner-pdftron]

Ive tried with and without and both produce the same results.

My build command is this:

asc assembly/index.ts -Oz -b build/output.wasm -a build/output.asm.js  --validate --optimize

When I import the ASM module, all the function names have a MyClass_ appended to it (im assuming because the functions are part of the MyClass class. I can work around this, but it would be nice to have the same interface between the WASM module and the ASM module.

Another thing i've noticed is that all the exported functions have one extra parameter attached. For example, if I have something like this:

function test(p1) {

}

the ASM module would contain this:

function MyClass_test($0, $1) {
   ...
}

and its unclear what the additional paramter should be.

Edit: Seems like just passing 0 as the first argument to every function makes everything work

[MaxGraey]

Additional parameter only appear for exported methods with optional arguments. This first argument actually is number of non-optional params (argc) and setup by __setargc before call. It should handle by loader in this part

[lbittner-pdftron]

Okay thanks for the info.

I guess the problem then is that the loader doesn't seem to handle the module properly. I stepped through it and it seems like it doesn't know how to handle exported classes. The code here is looking for a hash, but the function exported from the ASM module does not contain a hash, instead it looks like MyClass_constructor.

[dcodeIO]

What happens here is that Binaryen mangles the names of JS variables and functions that would otherwise be invalid. My expectation would be that this doesn't affect export names, though, but this might have changed with Binaryen moving to ES6 modules or something recently. Need to check.

Regarding

function MyClass_test($0, $1)

If that's a function MyClass#test, then $0 is the this argument, which is the memory address of the respective MyClass instance the method is called upon, followed by the actual function parameters. All instance methods, including constructors, do this. The only case where supplying 0 as the this argument is valid is when calling a constructor, as this tells the ctor to allocate on its own instead of reusing memory allocated by a subclass.

[dcodeIO]

Binaryen issue on export names: WebAssembly/binaryen#2310

[lbittner-pdftron]

Okay great, thats kind of what I figured. For now I'm fine manually transforming the function names.

As a side note - it would be great to be able to use the loader with the ASM.js files as well as WASM files. Currently it's looking like I will have to manually implement the utility functions that the loader provides (allocString, etc). If I get some time I can look into implementing this.

[lbittner-pdftron]

I was able to get the loader to work with ASM modules with just a few changes. (I also had to update Binaryen and do some post processing on the generated ASM file).

Updating Binaryen seems to have made all the tests fail though :( (although everything seems to be working fine).

I can clean this up and make it into a PR if you think it's useful?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.