Proposal: Support global names in name section

[dcodeIO]

Currently, the name section supports

Name Type	Code	Description
Module	0	Assigns a name to the module
Function	1	Assigns names to functions
Local	2	Assigns names to locals in functions

and I am currently updating Binaryen support for these, but found that global names are not supported. I'm not sure if this is already on the roadmap, but in case it isn't, I'd like to propose to extend the binary encoding as follows:

---

Name Type	Code	Description
...
Global	3	Assigns names to globals

Global names

The global names subsection is a name_map which assigns names to a subset of the global index space (both imports and module-defined).

Each global may be named at most once. Naming a global more than once results in the section being malformed.

To be consistent with function names, global names need not to be unique.

---

Let me know if this is already being thought of, or if there is more I can do to get globals included.

[binji]

There is an existing proposal for this, but it has not made much progress: https://github.com/WebAssembly/extended-name-section/blob/master/proposals/extended-name-section/Overview.md

[dcodeIO]

I see, thanks! On our end there isn't really a need to name anything other than globals right now, and this seems like low hanging fruit compared to the exhaustive list of namings proposed in the existing proposal. Makes me wonder if it might make sense to pull naming globals out of the proposal as a relatively uncontroversial and rather easy to implement preliminary addition? Opinions?

[binji]

I think the issue is less the number of names, and more just having someone push on it. This proposal is interesting in a way, since it is a change to the custom sections only. This does show up in the spec, but isn't in the reference interpreter or tests. So to advance we really need only tools + engine support, IMO.

[codefromthecrypt]

FWIW I think a big bang issue to add a lot of name subsections has shown by inaction to be the lesser way forward. Let's move this one? The name section for globals helps because it is otherwise hard to analyze wasm for what they are for. The more obvious part of this being unable to wasm2wat into something coherent (unless globals are exported by accident or intentionally).

Concrete example, it took some time to figure out the use of a global generated by emscripten. Eventually figured it out by reading source (__stack_pointer)

https://github.com/emscripten-core/emscripten/blob/main/system%2Flib%2Fcompiler-rt%2Fstack_ops.S

[sbc100]

The entire emscripten toolchain (emscripten, binaryen, llvm) as well as wabt already support for the extended names section. Are you building with -g (or --profiling-funcs) without which no names at all will be generated.

Here is an example showing that it works:

$ emcc -g hello.c

$ wasm-objdump -s a.out.wasm | grep global
 - global[0] i32 mutable=1 <__stack_pointer> - init i32=5245840
 - global[1] i32 mutable=1 <__stack_end> - init i32=0
 - global[2] i32 mutable=1 <__stack_base> - init i32=0
 - global[0] <__stack_pointer>
 - global[1] <__stack_end>
 - global[2] <__stack_base>

$ wasm2wat a.out.wasm | grep "(global"
  (global $__stack_pointer (mut i32) (i32.const 5245840))
  (global $__stack_end (mut i32) (i32.const 0))
  (global $__stack_base (mut i32) (i32.const 0))

Note that all the globals have names

[codefromthecrypt]

sorry this wasn't wasm I built personally, just had to reverse engineer what was in it.

[codefromthecrypt]

I appreciate that you have encoded the names btw, I think Wasm-tools also pre-emptively implemented features. There seems to be a severe stalling in the wasm ecosystem where all impls run ahead of specs some of them dormant for years. As a newcomer, this is a bit annoying to navigate.