This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Expose the offset of each data segment
ClosedPublic

Authored by sbc100 on Jul 10 2017, 6:04 PM.

Details

Summary

This allows tools like lld that process relocations
to apply data relocation correctly. This information
is required because relocation are stored as section
offset.

Diff Detail

Repository
rL LLVM

Event Timeline

sbc100 created this revision.Jul 10 2017, 6:04 PM
sbc100 updated this revision to Diff 105952.Jul 10 2017, 6:08 PM
  • remove debugging
sbc100 added a subscriber: llvm-commits.

@dschuff PTAL? (or sunfish if you have time?)

dschuff edited edge metadata.Jul 11 2017, 12:56 PM

So just to be sure I understand, we need this because we only have segments for initialized data (and there is implicitly BSS in between), so the offset can't just be calculated from the sizes of the segments?

include/llvm/Object/Wasm.h
82 ↗(On Diff #105952)

Maybe this should be called WasmObjectSegment or something like that WasmSegment made me think it should be some sort of generalization of data and elem segments, which are pretty similar, although we model them differently in LLVM. Or thinking of it another way, will we eventually want a similar model for elem segments (with an offset in the table instead of in the section?)

Actually I guess this is in the llvm:object namespace, so maybe ObjectSegment is redundant and this is unambiguous enough.

No the motivation is to allow the linker to know which relocations apply to a given segment. Since the relocations all defined as offsets in to the section. Does that make sense? We could go back to the drawing board and define relocations for each segment separately, but that also complicated the definition of relocations. Alternatively the linker could parse the data section itself rather then relying on the libObject abstraction.

dschuff accepted this revision.Jul 11 2017, 5:20 PM

OK, I got it; this is for the linker's use of the lib/object abstraction, that's what I was missing.

This revision is now accepted and ready to land.Jul 11 2017, 5:20 PM
This revision was automatically updated to reflect the committed changes.