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

[Eli Bendersky]

On Wed, Feb 20, 2013 at 3:15 PM, Eli Bendersky <eliben at google.com> wrote:
>>> 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.
>

Following a recent IRC discussion, just to point out what I mean
exactly. CIE headers in DWARF v4 have extra fields after augmentation:
address_size & segment size. Therefore, if you blindly assume you're
reading DWARFv3 and you get v4 as input, the parsing will be wrong.

The DWARF v4 standard states this explicitly in the introduction:

"
DWARF Version 4 is compatible with DWARF Version 3 except as follows:
  [...]
 * DWARF frame and line table sections include a additional fields
that affect the location
and interpretation of other data in the section.
"

DWARF comes with a version number (in the header of compilation
units), which can be used to parse such information conditionally on
the version. I imagine this is tools like GDB do (wanting to support
multiple versions).

Eli