Function name choices and multiple definitions

[jcbeyler]

Dear all,

I've had problems today with two test files. The first is f64.wast. My system used to be able to support it but I started trying to support float_exports.wast. Because of that latter test, I started convincing the LLVM backend to create multiple LLVM files, one per module + one for all the asserts.

But problems started to arise:

• For f64.wast, the methods exposed are the same as the libc names, which means that when I lower it, I end up in an infinite loop
  • The WASM trunc, calls the opcode trunc; I tell it to call trunc the llvm intrinsic but the way it works is that it lowers it as an infinite loop (trunc calls trunc...)
    • Of course, my belief is that Wasm should not care about it and I'll probably just put a prefix to all wasm methods to not have this issue but thought others writing compilers for Wasm might want to be careful of that.

A more annoying problem is this, consider the following test:
https://github.com/WebAssembly/spec/blob/master/ml-proto/test/exports.wast

It contains multiple modules and some define the same method (for example: $f32.no_fold_div_0).

Now the problem is: what do we do? Do we consider that this is legal or illegal to have a wasm file with multiple exported functions that have the same name (I can accept multiple functions with the same name that are not exported).

[sunfishcode]

Compiling wasm into code which will be linked in the presence of a native libc will require prefixing or otherwise mangling the wasm names.

It is indeed an accident that that test ended up with two modules with functions with the same name, however I believe that should be valid, because WebAssembly semantics describe modules, rather than files. Each module should be independent.

That said, I think supporting multiple modules per file was just introduced for the purpose of writing tests, and I don't know if that'll be carried forward into the official text or binary formats.

I'll probably rename that one function, because it was indeed unintentional (the code does the right thing, it just has the wrong name), but then we should add a new test which deliberately creates two modules in the same file with functions with the same name, to make sure we test this case :-).

[dschuff]

I agree that there should definitely not be a restriction on what wasm
modules can name functions, and that it shouldn't matter what overlap there
may be between modules. I do think it would be better for the official
formats to have one module per file, but multimodule files are so
convenient for writing tests that the capability may not go away entirely. FWIW
I just mangle all the function names with the module name and allow
multiple wasm modules per LLVM module (and generate freestanding assertion
functions with names based on their line numbers for debugging convenience)
. If you prefix the symbol names with something that's not valid in C
identifiers it solves both the module collision problem and the wasm/C
collision problem. (I went with . because it's not valid in C but it is
valid in assembler identifiers).

On Thu, Oct 15, 2015 at 3:43 PM Dan Gohman notifications@github.com wrote:

Compiling wasm into code which will be linked in the presence of a native
libc will require prefixing or otherwise mangling the wasm names.

It is indeed an accident that that test ended up with two modules with
functions with the same name, however I believe that should be valid,
because WebAssembly semantics describe modules, rather than files. Each
module should be independent.

That said, I think supporting multiple modules per file was just
introduced for the purpose of writing tests, and I don't know if that'll be
carried forward into the official text or binary formats.

I'll probably rename that one function, because it was indeed
unintentional (the code does the right thing, it just has the wrong name),
but then we should add a new function which deliberately creates two
modules in the same file with functions with the same name, to make sure we
test this case :-).

—
Reply to this email directly or view it on GitHub
#415 (comment).

[lukewagner]

The .wast files are specifically for testing. I'm definitely in favor of having whatever the real TextFormat.md be file-per-module.

[jcbeyler]

I might just be confused on to how export is supposed to work when trying to call it. For now, the modules I've seen in the tests are all anonymous so you export a function and then it becomes relatively a global method.

Is there a convention or somewhere where it is defined what to do when two exports are wanting to export the same name?

[dschuff]

I don't think one module is allowed to export 2 different functions with
the same name (or it shouldn't be, if it is today). Between 2 modules, wasm
has a 2-level namespace so it should be allowed to import 2 functions with
the same name from 2 different modules. It's up to the environment to
define what importing and exporting means and how modules are hooked up,
and that will obviously depend on the context. For a scenario where you
just link all the modules that can ever be called into one executable, then
you definitely have to mangle the names to avoid collisions (or make
everything anonymous at the symbol level and come up with some other name
lookup mechanism).

On Mon, Oct 19, 2015 at 2:25 PM jcbeyler notifications@github.com wrote:

I might just be confused on to how export is supposed to work when trying
to call it. For now, the modules I've seen in the tests are all anonymous
so you export a function and then it becomes relatively a global method.

Is there a convention or somewhere where it is defined what to do when two
exports are wanting to export the same name?

—
Reply to this email directly or view it on GitHub
#415 (comment).

[jcbeyler]

So instead of defining the collision in the design of Wasm we are saying that it is the environment's job to do it?

(Using wast filenames just because that is what we have now)

file1.wast

(module
...
(export "foo" 0)
)

file2.wast

(module
...
(export "foo" 0)
)

file3.wast

...
(call "foo")
...

Are we saying that the modules never export a global "foo" symbol but actually we would be exporting a file1::foo and file2::foo for example instead of just "foo"?

I'm just confused it seems :) so thanks for the answers!

[dschuff]

Basically, yes.
In particular, the concept of a "global symbol" is something that's defined
by the environment, and not by wasm itself, and the way that wasm module
export names map onto names in the environment is defined by the
environment. Even what the module names mean is defined by the environment.
e.g. on the web the module name in an import statement could be a URL, or
in a filesystem-based system a module name could be an absolute path, a
bare filename expected to be found in some linker search path, a name in
some kind of sandboxed virtual file system, or whatever kind of scheme you
want to invent.

On Tue, Oct 20, 2015 at 6:32 PM jcbeyler notifications@github.com wrote:

So instead of defining the collision in the design of Wasm we are saying
that it is the environment's job to do it?

(Using wast filenames just because that is what we have now)

file1.wast

(module
...
(export "foo" 0)
)

file2.wast

(module
...
(export "foo" 0)
)

file3.wast

...
(call "foo")
...

Are we saying that the modules never export a global "foo" symbol but
actually we would be exporting a file1::foo and file2::foo for example
instead of just "foo"?

I'm just confused it seems :) so thanks for the answers!

—
Reply to this email directly or view it on GitHub
#415 (comment).

[dschuff]

I think we're clear about this? Also we have relevant commits on https://github.com/WebAssembly/wasm-to-llvm-prototype/commits/master so we can close this for now.