[WebAssembly] Output provisional table to match LLD relocatable output

[ncw]

Summary

LLD now avoids duplicating functions in the output table, but the Clang logic does not match. To avoid unnecessary variability, this commit cleans up that difference in behaviour.

No functional changes. This is because the Wasm "table" in object files is purely cosmetic, and simply contains provisional values. LLD ignores its contents, and it simply exists to make the object file valid and look roughly right.

---

(This was the third chunk split out of D41954.)

[ncw]

test/MC/WebAssembly/external-func-address.ll

32

Test expectations updated: all ELEM sections are now written out with offset 1. Avoids unnecessary differences between the different Wasm files.

test/MC/WebAssembly/global-ctor-dtor.ll

124

Test expectations updated: all "preliminary" values for relocations are incremented by one (since the table now has offset 1).

test/MC/WebAssembly/weak-alias.ll

65

Test expectations now updated: in the alias test, the table is now one element smaller (here and line 134) since WasmObjectWriter now uses ResolveSymbol for the "provisional" ELEMS section - this matches the LLD behaviour, writing out the index of the actual function called rather than the import that's used as a stand-in for aliases.

[sbc100]

lib/MC/WasmObjectWriter.cpp

226

If this is constant then there no need to for it to be a member. Perhaps static const int in the file scope?

[sbc100]

I split off that table offset part of this change: D42284
And make a corresponding LLD-side change that can land first: D42285

I hope you don't mind me landing this stuff peicemeal. I think its better to be incremental.

[ncw]

Update:

• Simple rebase

I know you might be landing this one in a different order... I'm just keeping this sequence of patches updated and consistent on top of master, to help cherry-picking things across and making sure they all apply cleanly (I'm using git).

[ncw]

Updated:

• Another rebase after #4c and #4d landed

[ncw]

Updated:

• Rebased to avoid conflict after previous change was landed with some reformating

[sbc100]

Can you update the description of this change? I'm not sure all of it still applies.

lib/MC/WasmObjectWriter.cpp

216

Maps function index to table element index, no? Only functions can exist in this map right?

[sbc100]

lib/MC/WasmObjectWriter.cpp

216

Also, this isn't really map is it? It more a list of function indexes to be written to the indirect function table.

With that in mind, why not call it TableElems, perhaps?

511

This doesn't look like it should work to me.

TableIndices is not a map.. but a list of function indexes.. so it seems like this will look up the N'th element in the table, not the table entry for function N.

test/MC/WebAssembly/weak-alias.ll

196

How as this change generated a new data segment? I guess maybe it was zero before so now it was elided?

It looks to me like we really want to two different function addresses here for the address of the function itself and the address of the weak alias. Its not until link time that these two things become the same thing. Maybe it doesn't really matter as long as the linker can distinguish them, but it makes sense to be that there would be two different function addresses in this object file.

[ncw]

Thanks for the review!

lib/MC/WasmObjectWriter.cpp

216

Functions and function imports too. It's a map in the sense that it's an int->int lookup table; it's just a dense map with bounded elements so an array made sense.

TableIndices[i] is the table index of the ith function, so the name makes sense to me.

511

It's an array more than a vector really.

test/MC/WebAssembly/weak-alias.ll

196

Ah, the test data before was skipping the section - see the "CHECK" in the original file, rather than "CHECK-NEXT". I thought it was useful to expand the test to assert on the section that was being skipped; it was odd that previously it was deliberately not examining the final segment.

"It's not until link time that they become the same thing" -> but the table in the object file is linked. The "provisional" values that are used for relocations in the object file are a preview of the values that would get written out. I think it makes sense to use the same rules for writing out provisional values as we do for writing out the actual values in LLD. Hence we don't put the exact same function twice in the table - there's really no point. Seeing a function appear multiple times in the table doesn't make the output any easier to read.

[sbc100]

lib/MC/WasmObjectWriter.cpp

216

When we talk about "function index space" that always includes imported functions.

If that is the case then I think I prefer a map, since most functions are not address taken. I also don't see why you wouldn't want it to continue to a map that is indexed by symbol.

test/MC/WebAssembly/weak-alias.ll

196

But for intermediate output such as this (or the lld -r) we are still waiting for the a potential strong version of the symbol, so the weak alias and the function in points too are still district (both here and in lld -r).

[sbc100]

test/MC/WebAssembly/weak-alias.ll

196

Hmm.. maybe i'll expand this test expectation now as a separate change to make this change more explicit.

[ncw]

lib/MC/WasmObjectWriter.cpp

216

I see the code comment now, you're right the comment is anticipating a future change (should say "function index" not "function symbol index" since that doesn't exist yet).

I just did it because I thought the array would be "denser" in time/space, and take a bit less code than instantiating a map template. I suppose it doesn't matter, maybe using a DenseMap is clearer. I can make that change tomorrow.

test/MC/WebAssembly/weak-alias.ll

196

Yes - LLD might well resolve the indexes separately. But it doesn't seem to me that there's any added clarity in making the object file different to the linked output here (ie we're just outputting the same table that you'd get if you run LLD to link the single object file).

The output you're requesting is going to look like this. It doesn't seem to me to assist in examining the object file to put the same function twice in the table:

(table 3 anyfunc)
(elem (i32.const 1) $func $func)
(memory $0 1)
(export "memory" (memory $0))
(export "func" (func $func))
(export "funcAlias" (func $func)) // Weak alias for func
(func $func  (type blah)
)
(func $anotherFunc (type blah)
 // A call to the alias and a call to the non-alias...
 // But there's no way to tell which is which! The alias is weakly-
 // defined, so it's not an import
 (call_indirect 1)
 (call_indirect 2)
)

Of course the other alternative is just to output a totally empty table in object files!

[sbc100]

test/MC/WebAssembly/weak-alias.ll

196

I'm taking a look at the lld -r output now. I'm sure we can agree that the clang output should match that of lld -r more that it matches just lld right?

It does looks like lld -r currently doesn't do the useful thing I was expecting.

The output if wasm-objdump -x -d -r a lot more useful to me that anything in llvm right now (until we can disassembly wasm files, which is coming soon). Hopefully we will have better tools that objtoyaml to use in our test cases at some point.

In this case I modified lld/test/wasm/weak-alias.ll to use --relocatable and I got the following:

0000cd <call_alias_ptr>:
 0000d1: 23 80 80 80 80 00          | get_global 0
           0000d2: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 0000d7: 41 10                      | i32.const 16
 0000d9: 6b                         | i32.sub
 0000da: 22 00                      | tee_local 0
 0000dc: 24 80 80 80 80 00          | set_global 0
           0000dd: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 0000e2: 20 00                      | get_local 0
 0000e4: 41 80 80 80 80 00          | i32.const 0
           0000e5: R_WEBASSEMBLY_TABLE_INDEX_SLEB 1
 0000ea: 36 02 08                   | i32.store 2 8
 0000ed: 10 81 80 80 80 00          | call 1 <direct_fn>
           0000ee: R_WEBASSEMBLY_FUNCTION_INDEX_LEB 1 <direct_fn>
 0000f3: 21 01                      | set_local 1
 0000f5: 20 00                      | get_local 0
 0000f7: 41 10                      | i32.const 16
 0000f9: 6a                         | i32.add
 0000fa: 24 80 80 80 80 00          | set_global 0
           0000fb: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 000100: 20 01                      | get_local 1
 000102: 0b                         | end

and

000103 <call_direct_ptr>:
 000107: 23 80 80 80 80 00          | get_global 0
           000108: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 00010d: 41 10                      | i32.const 16
 00010f: 6b                         | i32.sub
 000110: 22 00                      | tee_local 0
 000112: 24 80 80 80 80 00          | set_global 0
           000113: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 000118: 20 00                      | get_local 0
 00011a: 41 81 80 80 80 00          | i32.const 1
           00011b: R_WEBASSEMBLY_TABLE_INDEX_SLEB 1
 000120: 36 02 08                   | i32.store 2 8
 000123: 10 81 80 80 80 00          | call 1 <direct_fn>
           000124: R_WEBASSEMBLY_FUNCTION_INDEX_LEB 1 <direct_fn>
 000129: 21 01                      | set_local 1
 00012b: 20 00                      | get_local 0
 00012d: 41 10                      | i32.const 16
 00012f: 6a                         | i32.add
 000130: 24 80 80 80 80 00          | set_global 0
           000131: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 000136: 20 01                      | get_local 1
 000138: 0b                         | end

I was hoping that the two R_WEBASSEMBLY_FUNCTION_INDEX_LEB entries where would be different, as I think they should be. So I think that might be bug in the --relocatable output generation.

[ncw]

test/MC/WebAssembly/weak-alias.ll

196

Yes, I agree Clang should most closely match lld -r - but I was hoping that *both* of them would match normal LLD output for the table (ie one table entry per "real" function). If there is to be any difference between object files and linked files in terms of the table that's output, Clang and lld -r should match.

The relocations should definitely be different, and reference the two different symbols directly. But since those two symbols each reference the same (Wasm) function index, I personally would find it odd to have multiple table indices for the same Wasm function.

I think you're right that there is a bug in the lld -r output for relocations, but it's worth checking whether #5 fixes it? The handling of symbols vs functions in LLD is generally a bit patchy, and I think #5 fixes the overall approach.

This is after all cosmetic, I really don't mind what the outcome is! I was trying to make Clang, lld -r, and normal LLD make a matching table, so that we don't have unnecessary variability.

[ncw]

Updated:

• Renamed table map as requested, tidied diff slightly

Also split out a small chunk from patch #5 into a separate revision, #4f (D42476).

test/MC/WebAssembly/weak-alias.ll

196

Aha - wait! I must have been very sleepy last night to forget why lld -r doesn't work with aliases!

It's because your "double symbol fix" (so that aliases are both imported and exported) with the "alt index" isn't present in LLD. WasmObjectWriter hackily writes out the weak symbols twice, but LLD only has support for reading in twice-declared symbols, not for writing them out.

There really isn't any point fixing this. Why introduce new code in LLD at this stage, for writing out the import-and-export format, when we're just days away from switching to using symbol indexes, at which point the need for doing that goes away.

So that's why the fix isn't split out of patch #5.

I see you've added a test - that's great, I'll check that #5 does indeed fix that test.

[ncw]

test/MC/WebAssembly/weak-alias.ll

196

Oops - when I said "there really isn't any point fixing this", what I meant was, there really isn't any point fixing LLD so that lld -r output matches what Clang currently outputs. Namely, I don't see any point adding code to LLD to make the -r output use the imports/exports strategy that Clang currently has.

Of course it's worth fixing in the long run, with the symtab changes.

I've tested with #5, and can confirm that LLD does indeed write out the expected relocations:

0000cc <call_alias_ptr>:
 0000d0: 23 80 80 80 80 00          | get_global 0
           0000d1: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 0000d6: 41 10                      | i32.const 16
 0000d8: 6b                         | i32.sub
 0000d9: 22 00                      | tee_local 0
 0000db: 24 80 80 80 80 00          | set_global 0
           0000dc: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 0000e1: 20 00                      | get_local 0
 0000e3: 41 81 80 80 80 00          | i32.const 1
           0000e4: R_WEBASSEMBLY_TABLE_INDEX_SLEB 7
 0000e9: 36 02 08                   | i32.store 2 8
 0000ec: 10 81 80 80 80 00          | call 1 <direct_fn>
           0000ed: R_WEBASSEMBLY_FUNCTION_INDEX_LEB 7
 0000f2: 21 01                      | set_local 1
 0000f4: 20 00                      | get_local 0
 0000f6: 41 10                      | i32.const 16
 0000f8: 6a                         | i32.add
 0000f9: 24 80 80 80 80 00          | set_global 0
           0000fa: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 0000ff: 20 01                      | get_local 1
 000101: 0b                         | end

000102 <call_direct_ptr>:
 000106: 23 80 80 80 80 00          | get_global 0
           000107: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 00010c: 41 10                      | i32.const 16
 00010e: 6b                         | i32.sub
 00010f: 22 00                      | tee_local 0
 000111: 24 80 80 80 80 00          | set_global 0
           000112: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 000117: 20 00                      | get_local 0
 000119: 41 81 80 80 80 00          | i32.const 1
           00011a: R_WEBASSEMBLY_TABLE_INDEX_SLEB 2
 00011f: 36 02 08                   | i32.store 2 8
 000122: 10 81 80 80 80 00          | call 1 <direct_fn>
           000123: R_WEBASSEMBLY_FUNCTION_INDEX_LEB 2 <call_direct>
 000128: 21 01                      | set_local 1
 00012a: 20 00                      | get_local 0
 00012c: 41 10                      | i32.const 16
 00012e: 6a                         | i32.add
 00012f: 24 80 80 80 80 00          | set_global 0
           000130: R_WEBASSEMBLY_GLOBAL_INDEX_LEB 0
 000135: 20 01                      | get_local 1
 000137: 0b                         | end

We have two instances of call 1 <direct_fn>, but the relocations are different indices. Clearly wasm-objdump is going to have to be updated to understand the new relocation format... maybe wait until the symtab format is stable.

[sbc100]

Is this change still worth landing with planned symbol table changes coming down the line?

[ncw]

In D42095#992828, @sbc100 wrote:

Is this change still worth landing with planned symbol table changes coming down the line?

Yes! This change is just to do with the provisional indexes - which are Wasm indexes, and won't change with all the symbol table changes. The code & tests affected by this change aren't touched by any of my later commits.

[ncw]

Updated to remove conflicts, no real changes

[sbc100]

lib/MC/WasmObjectWriter.cpp

504–505

I guess this error was removed because it should never happen right?

And converting it to an assert wouldn't be very useful?

[sbc100]

Ok, I'm about to land this. What do you think of my proposed description:

[WebAssembly] MC: Resolve aliases when creating provisional table entries
    
This change is useful for the upcoming addition of the symbol
table (D41954) since in that world function aliases all share
the same function index.
    
This change does not effect lld because the wasm "table" in
object file format is purely cosmetic and lld ignores its
contents.

[dschuff]

In D42095#993612, @sbc100 wrote:

This change does not effect lld because the wasm "table" in
object file format is purely cosmetic and lld ignores its
contents.

Is "cosmetic" the right term? Is it really to ensure that the object file still validates?

[sbc100]

In D42095#993639, @dschuff wrote:

In D42095#993612, @sbc100 wrote:

This change does not effect lld because the wasm "table" in
object file format is purely cosmetic and lld ignores its
contents.

Is "cosmetic" the right term? Is it really to ensure that the object file still validates?

I can reword. The key is that lld basically ignores it.

[ncw]

Thanks! Description looks good. (Could be "affect" :) )

lib/MC/WasmObjectWriter.cpp

504–505

Hmm, maybe it would be better to keep the check. In fact, there are several places where we do a check using "!thing.count()", when we could instead be using "find" to do the lookup only once. That would be ideal I guess, maybe with "findOrAbort" static helper function.

[sbc100]

lib/MC/WasmObjectWriter.cpp

504–505

Doesn't std::vector::operator[] effectively give us the "findOrAbort" semantics?

I think I originally added this nice errors to aid debugging, but if they shouldn't ever occur in practice then we should probably at most use a single assert (and perhaps just really on std::vector to blow up for us?)

[ncw]

lib/MC/WasmObjectWriter.cpp

504–505

I think it's actually a map, so it currently has "insert null if not present" semantics. So there will be a null-dereference crash which effectively an assert.

Feel free to add an assert when committing - or I can update the diff if you'd prefer?

What at lot of trouble over a small change, I'm sorry about this.

lib/MC/WasmObjectWriter.cpp

class WasmObjectWriter : public MCObjectWriter {
   std::vector<WasmRelocationEntry> CodeRelocations;
 
   // Relocations for fixing up references in the data section.
   std::vector<WasmRelocationEntry> DataRelocations;
 
   // Index values to use for fixing up call_indirect type indices.
   // Maps function symbols to the index of the type of the function
   DenseMap<const MCSymbolWasm *, uint32_t> TypeIndices;
-  // Maps function symbols to the table element index space. Used
-  // for TABLE_INDEX relocation types (i.e. address taken functions).
-  DenseMap<const MCSymbolWasm *, uint32_t> IndirectSymbolIndices;
   // Maps function/global symbols to the function/global index space.
   DenseMap<const MCSymbolWasm *, uint32_t> SymbolIndices;
+  // Maps function symbol indices to the table element index space. Used
+  // for TABLE_INDEX relocation types (i.e. address taken functions).
+  SmallVector<int32_t, 4> TableIndices;
 
   DenseMap<WasmFunctionType, int32_t, WasmFunctionTypeDenseMapInfo>
       FunctionTypeIndices;
   SmallVector<WasmFunctionType, 4> FunctionTypes;
   SmallVector<WasmGlobal, 4> Globals;
   unsigned NumFunctionImports = 0;
   unsigned NumGlobalImports = 0;
+  unsigned InitialTableOffset = 1;
 
   // TargetObjectWriter wrappers.
   bool is64Bit() const { return TargetObjectWriter->is64Bit(); }
   unsigned getRelocType(const MCValue &Target, const MCFixup &Fixup) const {
     return TargetObjectWriter->getRelocType(Target, Fixup);
   }
 
   void startSection(SectionBookkeeping &Section, unsigned SectionId,

 private:
   ~WasmObjectWriter() override;
 
   void reset() override {
     CodeRelocations.clear();
     DataRelocations.clear();
     TypeIndices.clear();
     SymbolIndices.clear();
-    IndirectSymbolIndices.clear();
+    TableIndices.clear();
     FunctionTypeIndices.clear();
     FunctionTypes.clear();
     Globals.clear();
     MCObjectWriter::reset();
     NumFunctionImports = 0;
     NumGlobalImports = 0;
   }
 

 
 // Compute a value to write into the code at the location covered
 // by RelEntry. This value isn't used by the static linker, since
 // we have addends; it just serves to make the code more readable
 // and to make standalone wasm modules directly usable.
 uint32_t
 WasmObjectWriter::getProvisionalValue(const WasmRelocationEntry &RelEntry) {
   const MCSymbolWasm *Sym = ResolveSymbol(*RelEntry.Symbol);
 
   // For undefined symbols, use zero
   if (!Sym->isDefined())
     return 0;
 
   uint32_t GlobalIndex = SymbolIndices[Sym];
   const WasmGlobal& Global = Globals[GlobalIndex - NumGlobalImports];
   uint64_t Address = Global.InitialValue + RelEntry.Addend;
 
   // Ignore overflow. LLVM allows address arithmetic to silently wrap.
   uint32_t Value = Address;
 
   return Value;
 }
 
-// Get a provisional table index.  This isn't used by the linker at all;
-// for now we'll write out the same value that we always have. TODO make neater
+// Get a provisional table index.  For table relocations, the relocation
+// entry contains the actual function symbol index, and that's all that's
+// used by the linker. However, as a nice touch so that the object files
+// "work", we create provisional table and table indexes just for show.
 uint32_t WasmObjectWriter::getProvisionalTableIndex(
     const WasmRelocationEntry &RelEntry) {
-  if (!IndirectSymbolIndices.count(RelEntry.Symbol))
-    report_fatal_error("symbol not found in table index space: " +
+  const MCSymbolWasm *Sym = ResolveSymbol(*RelEntry.Symbol);
+  assert(Sym->isFunction());
+  if (!SymbolIndices.count(Sym))
+    report_fatal_error("symbol not found in function/global index space: " +
                        RelEntry.Symbol->getName());
-  return IndirectSymbolIndices[RelEntry.Symbol];
+  uint32_t SymbolIndex = SymbolIndices[Sym];
+  int32_t TableIndex = TableIndices[SymbolIndex];
+  if (TableIndex < 0)
+    report_fatal_error("symbol not found in table index space: " +
+                       Sym->getName());
+  return TableIndex;
 }
 
 static void addData(SmallVectorImpl<char> &DataBytes,
                     MCSectionWasm &DataSection) {
   DEBUG(errs() << "addData: " << DataSection.getSectionName() << "\n");
 
   DataBytes.resize(alignTo(DataBytes.size(), DataSection.getAlignment()));
 
void WasmObjectWriter::writeElemSection(ArrayRef<uint32_t> TableElems) {
   SectionBookkeeping Section;
   startSection(Section, wasm::WASM_SEC_ELEM);
 
   encodeULEB128(1, getStream()); // number of "segments"
   encodeULEB128(0, getStream()); // the table index
 
   // init expr for starting offset
   write8(wasm::WASM_OPCODE_I32_CONST);
-  encodeSLEB128(0, getStream());
+  encodeSLEB128(InitialTableOffset, getStream());
   write8(wasm::WASM_OPCODE_END);
 
   encodeULEB128(TableElems.size(), getStream());
   for (uint32_t Elem : TableElems)
     encodeULEB128(Elem, getStream());
 
   endSection(Section);
 }
for (const MCSymbol &S : Asm.symbols()) {
     DEBUG(dbgs() << "  -> export " << Exports.size() << "\n");
     Exports.push_back(Export);
 
     if (!WS.isExternal())
       SymbolFlags.emplace_back(WS.getName(), wasm::WASM_SYMBOL_BINDING_LOCAL);
   }
 
   {
+    TableIndices.resize(NumFunctionImports + Functions.size(), -1);
     auto HandleReloc = [&](const WasmRelocationEntry &Rel) {
-      // Functions referenced by a relocation need to prepared to be called
-      // indirectly.
-      const MCSymbolWasm& WS = *Rel.Symbol;
-      if (WS.isFunction() && IndirectSymbolIndices.count(&WS) == 0) {
-        switch (Rel.Type) {
-        case wasm::R_WEBASSEMBLY_TABLE_INDEX_I32:
-        case wasm::R_WEBASSEMBLY_TABLE_INDEX_SLEB:
-        case wasm::R_WEBASSEMBLY_MEMORY_ADDR_I32:
-        case wasm::R_WEBASSEMBLY_MEMORY_ADDR_SLEB: {
-          uint32_t Index = SymbolIndices.find(&WS)->second;
-          IndirectSymbolIndices[&WS] = TableElems.size();
-          DEBUG(dbgs() << "  -> adding to table: " << TableElems.size() << "\n");
-          TableElems.push_back(Index);
-          registerFunctionType(WS);
-          break;
-        }
-        default:
-          break;
-        }
+      // Functions referenced by a relocation need to put in the table.  This is
+      // purely to make the object file's provisional values readable, and is
+      // ignored by the linker, which re-calculates the relocations itself.
+      if (Rel.Type != wasm::R_WEBASSEMBLY_TABLE_INDEX_I32 &&
+          Rel.Type != wasm::R_WEBASSEMBLY_TABLE_INDEX_SLEB)
+        return;
+      assert(Rel.Symbol->isFunction());
+      const MCSymbolWasm* WS = ResolveSymbol(*Rel.Symbol);
+      uint32_t SymbolIndex = SymbolIndices[WS];
+      if (TableIndices[SymbolIndex] == -1) {
+        TableIndices[SymbolIndex] = TableElems.size() + InitialTableOffset;
+        TableElems.push_back(SymbolIndex);
       }
     };
 
     for (const WasmRelocationEntry &RelEntry : CodeRelocations)
       HandleReloc(RelEntry);
     for (const WasmRelocationEntry &RelEntry : DataRelocations)
       HandleReloc(RelEntry);
   }

test/MC/WebAssembly/external-func-address.ll

 ; CHECK:            - Module:          env
 ; CHECK-NEXT:         Field:           f1
 ; CHECK-NEXT:         Kind:            FUNCTION
 ; CHECK-NEXT:         SigIndex:        0
 ; CHECK:        - Type:            ELEM
 ; CHECK-NEXT:     Segments:
 ; CHECK-NEXT:       - Offset:
 ; CHECK-NEXT:           Opcode:          I32_CONST
-; CHECK-NEXT:           Value:           0
+; CHECK-NEXT:           Value:           1
 ; CHECK-NEXT:         Functions:       [ 0 ]
 ; CHECK:        - Type:            DATA
 ; CHECK-NEXT:     Relocations:
 ; CHECK-NEXT:       - Type:            R_WEBASSEMBLY_TABLE_INDEX_I32
 ; CHECK-NEXT:         Index:           0
 ; CHECK-NEXT:         Offset:          0x00000006

test/MC/WebAssembly/global-ctor-dtor.ll

 ; CHECK-NEXT:         Index:           8
 ; CHECK-NEXT:       - Name:            global1
 ; CHECK-NEXT:         Kind:            GLOBAL
 ; CHECK-NEXT:         Index:           1
 ; CHECK-NEXT:   - Type:            ELEM
 ; CHECK-NEXT:     Segments:        
 ; CHECK-NEXT:       - Offset:          
 ; CHECK-NEXT:           Opcode:          I32_CONST
-; CHECK-NEXT:           Value:           0
+; CHECK-NEXT:           Value:           1
 ; CHECK-NEXT:         Functions:       [ 5, 7 ]
 ; CHECK-NEXT:   - Type:            CODE
 ; CHECK-NEXT:     Relocations:     
 ; CHECK-NEXT:       - Type:            R_WEBASSEMBLY_FUNCTION_INDEX_LEB
 ; CHECK-NEXT:         Index:           0
 ; CHECK-NEXT:         Offset:          0x00000004
 ; CHECK-NEXT:       - Type:            R_WEBASSEMBLY_TABLE_INDEX_SLEB
 ; CHECK-NEXT:         Index:           5

 ; CHECK-NEXT:         Index:           1
 ; CHECK-NEXT:         Offset:          0x00000045
 ; CHECK-NEXT:     Functions:       
 ; CHECK-NEXT:       - Index:           5
 ; CHECK-NEXT:         Locals:          
 ; CHECK-NEXT:         Body:            1080808080000B
 ; CHECK-NEXT:       - Index:           6
 ; CHECK-NEXT:         Locals:          
-; CHECK-NEXT:         Body:            024041808080800041004180808080001081808080000D000F0B00000B
+; CHECK-NEXT:         Body:            024041818080800041004180808080001081808080000D000F0B00000B
 ; CHECK-NEXT:       - Index:           7
 ; CHECK-NEXT:         Locals:          
 ; CHECK-NEXT:         Body:            1082808080000B
 ; CHECK-NEXT:       - Index:           8
 ; CHECK-NEXT:         Locals:          
-; CHECK-NEXT:         Body:            024041818080800041004180808080001081808080000D000F0B00000B
+; CHECK-NEXT:         Body:            024041828080800041004180808080001081808080000D000F0B00000B
 ; CHECK-NEXT:   - Type:            DATA
 ; CHECK-NEXT:     Segments:        
 ; CHECK-NEXT:       - SectionOffset:   6
 ; CHECK-NEXT:         MemoryIndex:     0
 ; CHECK-NEXT:         Offset:          
 ; CHECK-NEXT:           Opcode:          I32_CONST
 ; CHECK-NEXT:           Value:           0
 ; CHECK-NEXT:         Content:         '01040000'

test/MC/WebAssembly/weak-alias.ll

 ; CHECK-NEXT:         Memory:
 ; CHECK-NEXT:           Initial:         0x00000001
 ; CHECK-NEXT:       - Module:          env
 ; CHECK-NEXT:         Field:           __indirect_function_table
 ; CHECK-NEXT:         Kind:            TABLE
 ; CHECK-NEXT:         Table:
 ; CHECK-NEXT:           ElemType:        ANYFUNC
 ; CHECK-NEXT:           Limits:
-; CHECK-NEXT:             Initial:         0x00000002
+; CHECK-NEXT:             Initial:         0x00000001
 ; CHECK-NEXT:       - Module:          env
 ; CHECK-NEXT:         Field:           foo_alias
 ; CHECK-NEXT:         Kind:            FUNCTION
 ; CHECK-NEXT:         SigIndex:        0
 ; CHECK-NEXT:       - Module:          env
 ; CHECK-NEXT:         Field:           bar_alias
 ; CHECK-NEXT:         Kind:            GLOBAL
 ; CHECK-NEXT:         GlobalType:      I32

 ; CHECK-NEXT:         Index:           1
 ; CHECK-NEXT:       - Name:            bar_alias
 ; CHECK-NEXT:         Kind:            GLOBAL
 ; CHECK-NEXT:         Index:           3
 ; CHECK-NEXT:   - Type:            ELEM
 ; CHECK-NEXT:     Segments:        
 ; CHECK-NEXT:       - Offset:          
 ; CHECK-NEXT:           Opcode:          I32_CONST
-; CHECK-NEXT:           Value:           0
-; CHECK-NEXT:         Functions:       [ 1, 0 ]
+; CHECK-NEXT:           Value:           1
+; CHECK-NEXT:         Functions:       [ 1 ]
 ; CHECK-NEXT:   - Type:            CODE
 ; CHECK-NEXT:     Relocations:     
 ; CHECK-NEXT:       - Type:            R_WEBASSEMBLY_FUNCTION_INDEX_LEB
 ; CHECK-NEXT:         Index:           1
 ; CHECK-NEXT:         Offset:          0x00000009
 ; CHECK-NEXT:       - Type:            R_WEBASSEMBLY_FUNCTION_INDEX_LEB
 ; CHECK-NEXT:         Index:           0
 ; CHECK-NEXT:         Offset:          0x00000012

 ; CHECK-NEXT:           Opcode:          I32_CONST
 ; CHECK-NEXT:           Value:           0
 ; CHECK-NEXT:         Content:         '07000000'
 ; CHECK-NEXT:       - SectionOffset:   15
 ; CHECK-NEXT:         MemoryIndex:     0
 ; CHECK-NEXT:         Offset:          
 ; CHECK-NEXT:           Opcode:          I32_CONST
 ; CHECK-NEXT:           Value:           8
-; CHECK-NEXT:         Content:         '00000000'
-
-; CHECK:        - Type:            CUSTOM
+; CHECK-NEXT:         Content:         '01000000'
+; CHECK-NEXT:       - SectionOffset:   24
+; CHECK-NEXT:         MemoryIndex:     0
+; CHECK-NEXT:         Offset:
+; CHECK-NEXT:           Opcode:          I32_CONST
+; CHECK-NEXT:           Value:           16
+; CHECK-NEXT:         Content:         '01000000'
+; CHECK-NEXT:   - Type:            CUSTOM
 ; CHECK-NEXT:     Name:            name
 ; CHECK-NEXT:     FunctionNames:   
 ; CHECK-NEXT:       - Index:           1
 ; CHECK-NEXT:         Name:            foo
 ; CHECK-NEXT:       - Index:           2
 ; CHECK-NEXT:         Name:            call_direct
 ; CHECK-NEXT:       - Index:           3
 ; CHECK-NEXT:         Name:            call_alias