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.
Details
Diff Detail
- Repository
- rLLD LLVM Linker
- Build Status
Buildable 13753 Build 13753: arc lint + arc unit
Event Timeline
wasm/Writer.cpp | ||
---|---|---|
447 | 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? |
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.
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.
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?