This allows tools like lld that process relocations
to apply data relocation correctly. This information
is required because relocation are stored as section
offset.
Details
Diff Detail
- Build Status
Buildable 8117 Build 8117: arc lint + arc unit
Event Timeline
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 | 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.
OK, I got it; this is for the linker's use of the lib/object abstraction, that's what I was missing.
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.