On 02.11.2011, at 02:31, Nick Lewycky wrote:
> 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?
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