This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Don't allow functions to be named more than once
ClosedPublic

Authored by sbc100 on Jan 11 2018, 6:36 PM.

Details

Summary

Even though a function can have multiple names in the
linking standards (i.e. due to alias), there can only
be one name for a given function in the NAME section.

Event Timeline

sbc100 created this revision.Jan 11 2018, 6:36 PM
sbc100 updated this revision to Diff 129565.Jan 11 2018, 6:37 PM
  • cleanup
sbc100 updated this revision to Diff 129567.Jan 11 2018, 6:39 PM

clang-format

ruiu added inline comments.Jan 11 2018, 6:43 PM
wasm/Writer.cpp
445

In lld we carefully avoid using hash table because hash table is slow. In general, we lookup the hash table (the SymbolTable) only once for a name, and don't insert symbol names into any other hash tables. Can you avoid doing that here?

sbc100 updated this revision to Diff 129569.Jan 11 2018, 6:59 PM
  • avoid extra hash
sbc100 updated this revision to Diff 129570.Jan 11 2018, 7:01 PM
  • add comment
ruiu accepted this revision.Jan 11 2018, 7:24 PM

LGTM

This revision is now accepted and ready to land.Jan 11 2018, 7:24 PM
ncw added a subscriber: ncw.Jan 12 2018, 2:54 AM

I've just rewritten the name handling in D41955. What I did there was to associate the name with the Function (not the Symbol) since that's conceptually what the "names" section is (the debugger's name for the function body itself).

My solution was to simply iterate over DefinedFunctions when creating the "names" section in LLD. The names are attached to functions, either from their export name, or from their name specified in the names section. Writer::createNameSection is therefore shorter, and makes more sense: the "names" section is really all about iterating over the Functions, not the Symbols.

Another case of two people tackling the same problem at once!

In D41975#974359, @ncw wrote:

I've just rewritten the name handling in D41955. What I did there was to associate the name with the Function (not the Symbol) since that's conceptually what the "names" section is (the debugger's name for the function body itself).

My solution was to simply iterate over DefinedFunctions when creating the "names" section in LLD. The names are attached to functions, either from their export name, or from their name specified in the names section. Writer::createNameSection is therefore shorter, and makes more sense: the "names" section is really all about iterating over the Functions, not the Symbols.

Another case of two people tackling the same problem at once!

I think are you right. One thing to note is that the names section can name imported functions, although its seems a lot less useful to do so. Anyway, if its OK with you I'll land this small change now and your change can build on this. This change also increases test coverage so you can be come confident when you refactor.

ncw accepted this revision.Jan 12 2018, 6:51 AM

Fine by me then!

Although the names section can name imports (oddly...) I don't think clang does this when it writes out object files; I don't see any reason for LLD to do that either. Imports are already named in a canonical way by the import name! I've preserved the behaviour just for the time being in my changes.

This revision was automatically updated to reflect the committed changes.