<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Wasm backend COMDAT support"
   href="https://bugs.llvm.org/show_bug.cgi?id=35533">35533</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>Wasm backend COMDAT support
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>libraries
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>trunk
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>enhancement
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Backend: WebAssembly
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>ncw@realvnc.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvm-bugs@lists.llvm.org
          </td>
        </tr></table>
      <p>
        <div>
        <pre>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)</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>