[PATCH] Add option to llvm-dwarfdump to dump .eh_frame sections.

[Eli Bendersky]

>> Erik, thanks for working on this. You're reusing the DWARFDebugFrame
>> class, but AFAIK there are subtle format differences between
>> .debug_frame and .eh_frame. E.g. check out this:
>> http://www.airs.com/blog/archives/460 and other resources.
>>
>> Thoughts?
>
> Two things:
> 1) I know the .eh_frame is different from a proper .debug_frame, but the main goal of the patch was to get at least some output. With the comment in DWARFContext::getDebugFrame() I thought that not showing any output for the .eh_frame was an oversight. More below...
> 2) the blog you mentioned is correct, but I couldn't find the magic 0xffffffff length marker in the x86_64 ABI docs (http://refspecs.linuxfoundation.org/elf/x86_64-abi-0.95.pdf, page 62). If I overlooked something, then please let me know! :-)
>

Not parsing .eh_frame at this point is not an oversight. It's a
conscious decision to start with .debug_frame which is better
documented by the DWARF standard, and then do the necessary adjustment
to support .eh_frame as well.

Depending on the augmentation string, .eh_frame CIE headers can
contain additional information before the instructions begin. Hence,
they will not correctly parse as .debug_frame CIEs. There may be other
differences.

My plan here was to collect information from several sources, such as
the blog mentioned above, the Linux Standard Base spec and the source
code of readelf (binutils). Yes, for .eh_frame we'll probably end up
adopting some customization of the .debug_frame parsing code, but I
wouldn't want to just enable it now because it passes on some specific
case just to crash and burn on more realistic cases. This is all void,
of course, if you show that it passes on a variety of real objects
with .eh_frame

CCing Eric and Benjamin who are involved in the development of debug
info related stuff.

> AFAIK, the .eh_frame section is nearly the same as a .debug_frame section, but it is restricted to Dwarf2, or a subset thereof. I'm assuming that you added dwarf[1-4] parsing, so I'm wondering if it would be a possible to restrict that parsing to Dwarf2-only with a flag. Or would that be a terrible hack?
>

The lib/DebugInfo code currently handles DWARF v3, which is (AFAIK)
what LLVM also generates.

Eli