supporting dwarf relocations

In ELF .o files with debug info, there are relocations applied to the DWARF sections. For example, when emitting offsets into the stringpool, we emit a relocation.

How should we support this? llvm-dwarfdump currently works by finding the relevant dwarf sections and passing them in to lib/DebugInfo. The relocations can be iterated over in lib/Object using the relocation_iterator.

Should dwarfdump apply its own relocations and hand DebugInfo a copy of the sections from the input file? Should DebugInfo take the Object and do relocations in its head as needed? How about a wrapper that provides a “relocated view” of a section, and we pass that around? At a high level, what ought these APIs look like? Who’s responsible for what?

Nick

The idea behind the decoupling of libObject and libDebugInfo is that other clients (e.g. LLDB) can use their own object file cracking code so it can support debug info from all kind of odd sources. DWARFContext can be used to lazily map only the required sections into memory, and if a client wishes, it can move the data out of memory again without invalidating the parsed structures.

If we want to keep that design, we can't pass an Object into libDebugInfo. The "relocated view" option sounds interesting, but I'm not sure if it's worth the additional complexity. For now I'd go with the copy. It'll waste a lot of memory though.

- Ben