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

Export of local symbols in .o files #29

Closed
sunfishcode opened this issue Dec 7, 2017 · 5 comments
Closed

Export of local symbols in .o files #29

sunfishcode opened this issue Dec 7, 2017 · 5 comments
Labels

Comments

@sunfishcode
Copy link
Member

sunfishcode commented Dec 7, 2017

This C:

static void foo(void) {}
void *bar(void) { return foo; }

currently compilers to this wasm:

(module
  (type (;0;) (func (result i32)))
  (type (;1;) (func))
  (func $bar (type 0) (result i32)
    i32.const 0)
  (func $foo (type 1))
  (table (;0;) 1 anyfunc)
  (memory (;0;) 0)
  (export "bar" (func $bar))
  (export "foo" (func $foo))
  (elem (i32.const 0) $foo))

It's surprising to see "barfoo" exported here, since it has internal name linkage. The linkage is recorded in the metadata, via WASM_SYM_BINDING_LOCAL, however it seems like it would be more wasm-like to just omit the export.

Local symbols are never comdat or weak and they don't have visibilities, so it seems like they could be omitted from the WASM_SYMBOL_INFO subsection altogether.

@binji
Copy link
Member

binji commented Dec 7, 2017

You mean foo right?

@sunfishcode
Copy link
Member Author

Yes; updated.

@sbc100
Copy link
Member

sbc100 commented Dec 7, 2017

This is mostly for compatibility with other formats. Local symbols are visible in the symbol table of ELF and appear in the output of nm for example:

$ nm  test.o 
0000000000000006 T bar
0000000000000000 t foo

The imports + exports is how we model the symbol table itself, so the only way to name a symbol right now is via an import or an export.

Also, although relocations point to globals and functions (not imports and exports), its helpful if there is a symbol name associated. Once the name section expands to include naming things other than functions we could revisit this.

Since the expected use case for these objects is as input to the linker I don't really see problem here. The local symbols will not be exported in the linked binary.

@sunfishcode
Copy link
Member Author

Thanks. I agree; it's not urgent.

For completeness, here's the link to the proposal to expand the name section: WebAssembly/design#1064.

@sbc100
Copy link
Member

sbc100 commented Jan 17, 2018

My current thinking is that we drop the NAME section completely from the object format, and only use it for the final binary. For the object format we want to more advanced concept of the symbol table. I'll open two new issues for (a) dropping NAME section from clang output files (b) creating a more advanced symbol table.

@sbc100 sbc100 closed this as completed Jan 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants