This is an archive of the discontinued LLVM Phabricator instance.

Revert "[WebAssembly] MC layer writes table symbols to object files"
ClosedPublic

Authored by sbc100 on Jan 25 2021, 10:19 PM.

Details

Summary

This reverts commit d806618636f8a82bfc3f620e1fad83af4d2a2575.
Review: https://reviews.llvm.org/D92215

We had issues where older version of wasm-ld were crashing if object
files contains this new symbol type. Even if they correctly report the
unknown symbol type they still can't handle the object as input. We
decided that the best stratagy here is to only generate these symbol
types if refernece types is enabled. Without reference types enabled we
should never geneate a table symbol or a TABLE_NUMBER relocation.

This revert is in addition to the one already reverted in
https://reviews.llvm.org/D95005.

The plan is to re-land these in updated form after the llvm 12 branch
point.

Diff Detail

Event Timeline

sbc100 created this revision.Jan 25 2021, 10:19 PM
sbc100 requested review of this revision.Jan 25 2021, 10:19 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 25 2021, 10:19 PM
sbc100 added a reviewer: dschuff.
tlively accepted this revision.Jan 25 2021, 10:31 PM
This revision is now accepted and ready to land.Jan 25 2021, 10:31 PM
This revision was landed with ongoing or failed builds.Jan 25 2021, 10:36 PM
This revision was automatically updated to reflect the committed changes.
wingo added a comment.Jan 26 2021, 1:25 AM

@sbc100 @tlively what is the relationship between wasm-ld versions and compiler versions? Surely it's not that any LD should accept anything from any compiler, right?

@sbc100 @tlively what is the relationship between wasm-ld versions and compiler versions? Surely it's not that any LD should accept anything from any compiler, right?

In general, we should strive to avoid breaking changes to object file format. There can be cases when object files built with a LLVM version X and consumed by LLVM version Y. For example a pre-built library (i.e. libMyGameEngine.a) which is distributed in binary form. Ideally that library should be re-usable across as many LLVM versions as possible.

Occasionally this is not possible. A couple of examples might be:

  1. Use of a new feature of wasm that requires new types of symbol/relocation (e.g. ref types)
  2. We decide to change the object format metadata layout (e.g. redesign the symbol table)

(1) breaks any object file that opts into using the new features but should not break object thats don't
(2) breaks *all* objects files and we really want to avoid that if we can. This is when we would bump the object file version number

In think what happened with this change is we probably should have done (1) but we inadvertently did (2). At least that is how I see it. @tlively would you agree?

wingo added a comment.Jan 26 2021, 8:14 AM

I agree that old object files should always be consumable by new linkers. But the reverse does not follow for me in an obvious way. Is there a bound on how old a wasm-ld is supported for new compilers? Like is it one major version, or six, or all of them?

I agree that old object files should always be consumable by new linkers. But the reverse does not follow for me in an obvious way. Is there a bound on how old a wasm-ld is supported for new compilers? Like is it one major version, or six, or all of them?

I think its more that we shouldn't break forward compatibility unless we need too. In this case it seems that we can avoid the breakage for those that don't explicitly opt into the new feature (reference types). The approach we chose to take here broke forward comat for *all* object files.. this is something can could consider doing one day, but I would like to minimize the number of times we do this (and reserve that action for something more like a complete re-design of the object format).

Yes, I agree. We advertise a stable object format with the goal of making the linker forward-compatible. The value we get from that is that users with different toolchain versions (for both Emscripten and WASI) can share libraries without worrying about version skew in either direction as long as a least common denominator of features is used.