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

[Erik Verbruggen]

On Feb 20, 2013, at 23:12, Eli Bendersky <eliben at google.com> wrote:

> On Wed, Feb 20, 2013 at 2:05 PM, Erik Verbruggen <erik.verbruggen at me.com> wrote:
>> Add option to llvm-dwarfdump to dump .eh_frame sections.
>> 
>> 
> 
> 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! :-)

> Also, I'm concerned about your test not being restricted to a specific
> architecture/triple. It may fail on platforms with different word size
> and other parameters. Where did you test it?

I properly tested it on MacOS 10.8 x86_64 (with clang ToT, clang from xcode, and the ancient gcc 4.2.1), and did a quick manual test on Linux x86 and x86_64. But you are right, it won't work on e.g. ARM and probably a lot of other platforms.

> P.S. I'm going out to send a patch to enhance DWARFDebugFrame with
> some initial CFA instruction parsing very soon. It shouldn't interfere
> with yours, though.

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?

-- Erik.