[PATCH] D43391: [WebAssembly] Separate out InputGlobal from InputChunk

[Nicholas Wilson via Phabricator via llvm-commits]

ncw added a comment.

I had a great idea on this last night - I think I've been misrepresenting globals somewhat. This came to me after Andreas Rossberg answered a question I had about globals.

They're actually more like //functions// than data! Our rather, they are used/accessed as data at runtime, but the Globals section of the Wasm file actually contains a function body for each global, which contains executable code that's run through the interpreter to give the global it's initial value.

I kept saying "globals are like a chunk in every way except that they don't have relocations" - but that's wrong, they //should// have relocations! The "body" for a global can contain a get_global instruction, which requires a relocation for its operand, so what's really been misleading is that thelinking conventions for wasm simply forgot to mention that the linker needs to handle a "reloc.GLOBAL" section.

I know what you're thinking - Nick, the front-end currently doesn't emit globals that contain a get_global instruction, so we don't need to process relocations for them. But the linking conventions should still specify it, regardless of the fact that the clang front-end doesn't yet emit them.

One thing's sure, fPIC and shared-objects and threading will find more uses for globals than we had before.

To conclude: I'm not trying to complicate things for globals, I'm just trying to use exactly the same tried-and-tested abstraction for them, that LLD is already right now using for functions and segments, rather than try and make up something new.

And since globals can contain relocations after all, they look a lot more like functions; treating them as chunks like the rest really should give us basically the least amount of code overall, as well as ensuring the various symbol types work in the same way for "free".


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D43391