llvm-dwarfdump and eh_frame

Hi,

I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish patch, or could somebody else fix it, or can I just commit the change to svn?

-- Erik.

Please submit a patch to llvm-commits, with a test case that exercises the fix.

Eli

Before I submit the patch, I was wondering if it would be better to add a -eh-frame option to llvm-dwarfdump, like in the dwarfdump utility. Otherwise the eh_frame section would be treaded as a debug_frame section. What do you think?

Also, how can I do a partial match on the output of dwarfdump/FileCheck? For example:
  pc=00527a01...08598611
.. is in the output, but the exact pc addresses do not matter when checking whether a line is in the output or not.

-- Erik.

You can use FileCheck's regex support to match values of a specific format or leave out the check for the offending line. FileCheck will skip to the next match in that case.

- Ben

llvm-dwarfdump currently doesn't support the .eh_frame section. It
only has initial support for the .debug_frame section (headers of CIEs
and FDEs are read and decoded, but not the instructions). I was
planning to add .eh_frame support at some point, so please let me know
if you also plan to work on this so we could coordinate.
In any case, .debug_frame is dumped with -debug-dump=frames, so
dumpung .eh_frame would probably make sense with -debug-dump=eh_frames
or something similar. It's more important to have the functionality in
lib/DebugInfo and llvm-dwarfdump; we can bikeshed the option name
later.

Eli