eh_frame is debug info too
Sasha Da Rocha Pinheiro
Mon Sep 17 21:18:00 GMT 2018
I have found a bug in Dyninst related to the fact that dwarf_begin_elf() won't create a (Dwarf *) handle given a stripped binary which contains the section ".eh_frame".
This section is sometimes generated to the detriment of ".debug_frames", which is omitted, while all info about frames are put in eh_frame.
Dyninst has already a whole abstraction in which keeps references to Dwarf handles depending on the info they have, such as type info, line info, and frame info. We do this in order to be able to load debug info from a different file other than the binary we are dealing with.
What happens now is that we try to create the handles to stripped file with ".eh_frame" and to the corresponding separate debug info binary but the first fails, and we don't get frame info. I know we could use dwarf_next_cfi() to go through the CIEs and FDEs in the stripped binary, but we wouldn't be able to use dwarf_cfi_addrframe and such. In addition to that we have this static map in which the key are Dwarf handles so that we can easily give a PC address to dwarf_cfi_addrframe.
So my point is: can we make dwarf_begin_elf() open binaries that only contain ".eh_frame" to further be able to call dwarf_cfi_addrframe?
To make it more clear, in a Dyninst class, at some point, only has a Dwarf * handle. It doesn't know if it is stripped with only ".eh_frame" or if it contains ".debug_frame" and/or "eh_frame".
What it does is try get both from the same handle as follows:
// Try to get dwarf data from .debug_frame
Dwarf_CFI * cfi = dwarf_getcfi(dbg);
// Try to get dwarf data from .eh_frame
Elf * elf = dwarf_getelf(dbg);
cfi = dwarf_getcfi_elf(elf);
Note that we try with dwarf_getcfi (for the .debug_frame section) giving the handle "dbg", and afterwards we have to get the Elf handle of this dwarf handle "dbg" to use dwarf_getcfi_elf (for the .eh_frame section).
More information about the Elfutils-devel