Initial support for dwarf fission sections (-gsplit-dwarf) on wasm.
The most interesting change is support for writing 2 files (.o and .dwo) in the
wasm object writer. My approach moves object-writing logic into its own function
and calls it twice, swapping out the endian::Writer (W) in between calls.
It also splits the import-preparation step into its own function (and skips it when writing a dwo).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Nice, fairly unintrusive actually. If you desperately wanted to fix the need for changing W dynamically, you could instead make it allocate a second WasmObjectWriter to write the dwo version? :)
llvm/lib/MC/MCAsmBackend.cpp | ||
---|---|---|
56–57 | change error message |
Seems reasonable. Do you think this way is cleaner than the way elf does it? Looks like ELF creates two different ELFWriter inside the ELFDwoObjectWriter subclass right?
Are we going need to wasm-ld tests to followup or is this really independent of the linker?
llvm/lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
224 | Kind of a same this change means changing so many line in this file .. |
Yeah, ELF splits ELFWriter out from ELFObjectWriter, and then instantiates it twice. It's all because ELFObjectWriter has to derive from MCObjectWriter which was clearly not designed with this in mind. I found the class split to be a bit awkward, but I don't really have strong feelings about it either way.
Are we going need to wasm-ld tests to followup or is this really independent of the linker?
It should be independent of the linker because the dwo files don't get linked by the linker. They can be used independently (or combined by the dwp tool but AFAIK it's simpler than the linker). And the object files are just the same as usual from the linker's perspective.
Yeah, ELF splits ELFWriter out from ELFObjectWriter, and then instantiates it twice. It's all because ELFObjectWriter has to derive from MCObjectWriter which was clearly not designed with this in mind. I found the class split to be a bit awkward, but I don't really have strong feelings about it either way.
I should add that what I do instead is just have one instance, and just reset the relevant state before calling writeOneObject again. So the structure is cleaner but the downside of that is that the state has to be manually reset.
I don't really grok the TargetFrameLowering::DwarfFrameBase part but everything else LGTM
llvm/lib/MC/WasmObjectWriter.cpp | ||
---|---|---|
1335 | Nit picking on this because I can't find anything else to complain about: |
change error message