[llvm-bugs] [Bug 35533] New: Wasm backend COMDAT support

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35533

            Bug ID: 35533
           Summary: Wasm backend COMDAT support
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: WebAssembly
          Assignee: unassignedbugs at nondot.org
          Reporter: ncw at realvnc.com
                CC: llvm-bugs at lists.llvm.org

In order to support C++, the Wasm target needs to support COMDATs.


### Aside - linkonce_odr and MachO

Alternatively, it might also be possible to get by with only linkonce_odr
support, similarly to how MachO does it.

Pros:
* linkonce_odr sounds like it will be simpler, since it's one flag to pass to
the linker rather than a map of strings

Cons:
* MachO may be less well understood than ELF (certainly by me!)
* Everything else in Wasm is ELF-ish at the moment
* MachO is known to be limited in various ways, and maybe more bits of MachO
need to be implemented as well as just linkonce_odr to get full C++ support
* There may be compat concerns for migrating existing Emscripten code? (Might
just be FUD, but I don't know...)
* COMDAT actually encodes more information, by linking data/globals/functions
together into one linkable object. The richer info should actually make LLD
simpler!


### Use-cases to support

inline const char* basicFunction() {
  // Ideally data like this wouldn't be duplicated for every
  // translation unit including basicFunction()
  return "string";
}

typedef const char* (*fnSig)();
fnSig takeInlineAddress() {
  // We must guarantee that if we pass the function pointer between
  // translation units, the pointers are equal!
  return &basicFunction;
}

struct InlineClass {
  InlineClass() {} // These are inline too
  ~InlineClass() {}
};

// This one is very nasty - the vtable goes in a COMDAT, and must be
// de-duplicated so that in all translation units the constructor sets the
// the vtable pointer to point to the same address.
template<typename T>
struct VirtualTemplClass {
  VirtualTemplClass() {}
  virtual ~VirtualTemplClass() {}
};
template struct VirtualTemplClass<void>;


### Work to cover

1. Must add COMDAT to the Wasm linkage data for LLD to read
2. Must avoid errors on encountering duplicate functions if taken from the same
COMDAT
3. Must "compress" the function table. Currently, the function tables from
every object file are simply concatenated, but they must instead be assigned
indexes exactly once so that each function has a unique function pointer, for
use by the relocations.
4. No need to worry about the types we export (we already make sure not to
write out the same type twice)
5. No need to worry about imports (again, they're only generated once per
Symtab entry, not once per input file)
6. Need to make sure that exports are duplicated
7. Must merge data segments that are duplicates due to COMDAT (eg vtables)
8. Must merge global variables pointing to those data segments (eg
address-of-vtable variables)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171205/61f543bb/attachment.html>