Hi,
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);
if (cfi)
{
cfi_data.push_back(cfi);
}
// Try to get dwarf data from .eh_frame
Elf * elf = dwarf_getelf(dbg);
cfi = dwarf_getcfi_elf(elf);
if (cfi)
{
cfi_data.push_back(cfi);
}
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).
Regards,
Sasha
