You are missing an important point. The current situation is not broken, both scenarios described here actually do work AFAICT.
When serializing the module, we "skip" WASM_TO_JS_FUNCTION and WASM_INTERPRETER_ENTRY code objects by emitting the illegal builtin (Builtins::kIllegal) instead (see https://cs.chromium.org/chromium/src/v8/src/snapshot/code-serializer.cc?rcl=165c183f7c47e7ff100baa5dd4d96948e239460b&l=312).
Hence, after deserialization, all call sites that called imported functions or redirected to the interpreter now call the stub for the illegal builtin instead.
Note, though, that this code is never used as is. It's always instantiated before being used, and as part of that instantiation, we will patch all code objects again, replacing all direct call site with the correct code object (from the code table), see https://cs.chromium.org/chromium/src/v8/src/wasm/module-compiler.cc?rcl=165c183f7c47e7ff100baa5dd4d96948e239460b&l=1057.

Wrappers for imported functions are skipped because they are recompiled at instantiation time anyway, and interpreter entries are skipped since breakpoints will be re-set after instantiation, creating new (instance-specific) interpreter entries, and patching the code *again* to call these.

I see an action item here anyway:
If we go back to the approach of using a std::map for patching call sites after (re-)instantiation ( crbug.com/735513 ), then for imports and interpreter entries we need to emit something which allows us to reconstruct which wasm function to call after deserialization.

Thanks for the clarification.

When you say "emit" (last para) - I remember you saying the interpreter holds on to a fixed array of wasm functions it replaced with calls to the interpreter. Is that what you're referring to?

Yes, for interpreter entries, this should work. But we also need to do something about imported functions. We do not want to serialize the wasm-to-js wrapper, since it contains a JSFunction. And it would just waste memory, since it is never reused anyway. 

We don't serialize the wasm-to-js wrapper.

And that's exactly the problem. All direct calls to imported functions call the illegal builtin after deserialization. Which means we need a way to tell which function they should really call.
The current approach extracts this from the wire bytes, which is what you want to change.

Oh - we probably used, before, those code objects that encoded inside their body the index of the function we wanted to call.

We could do something similar, and synthesize such placeholders when serializing; the alternative is reloc info.

From a bits-counting perspective, I'd prefer we tagged the id information onto the function rather than the call site, because there are/should be more of the latter. 

If we punt doing this to until we're off the GC heap, when we'll likely change the way we serialize, too, we can control that.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Taking this one.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/f717e7f5b214409352b98a69741a9a1bbd0b0ce2

commit f717e7f5b214409352b98a69741a9a1bbd0b0ce2
Author: Clemens Hammacher <clemensh@chromium.org>
Date: Mon Oct 15 14:46:09 2018

[wasm] Don't put interpreter entries in the code table

For serialization we are using the code table to find the code of all
functions. We want to serialize compiled code though, not interpreter
entries (we currently fail a DCHECK there).
This CL changes the logic to not update the code table with interpreter
entries but instead keeps a separate bit set of interpreted functions.

R=mstarzinger@chromium.org

Bug:  v8:8177 ,  chromium:735509 
Change-Id: I69c59f92712135ddef667b54114614fad94cc6fc
Reviewed-on: https://chromium-review.googlesource.com/c/1278794
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56644}
[modify] https://crrev.com/f717e7f5b214409352b98a69741a9a1bbd0b0ce2/src/wasm/wasm-code-manager.cc
[modify] https://crrev.com/f717e7f5b214409352b98a69741a9a1bbd0b0ce2/src/wasm/wasm-code-manager.h
[modify] https://crrev.com/f717e7f5b214409352b98a69741a9a1bbd0b0ce2/test/mjsunit/wasm/interpreter.js