- dwarf_next_cfi () has the following comment:
"On success, returns 0 and fills in *ENTRY; use dwarf_cfi_cie_p to
see whether ENTRY->cie or ENTRY->fde is valid."
But dwarf_cfi_cie_p is only defined in the private cfi.h header.
Hmm. That was probably just an oversight.
I think your change to move it is fine.
- There is dwarf_next_cfi () which you can use to walk through the
raw
section data, which gives you a Dwarf_CFI_Entry. And there is
dwarf_cfi_addrframe () which you can use to query an address for the
corresponding Dwarf_Frame for an address. Ideally I would like to
get a dwarf_cfi_frame_next () to walk through all the FDEs.
You can use dwarf_addrframe on the end PC of the last one.
But I guess that doesn't help you when there are gaps.
And
something like a dwarf_frame_cie () and dwarf_frame_fde () that
provided the info in the the cfi.h dwarf_cie and dwarf_fde structs.
This is probably a bit specific to the systemtap use case, where we
want to preprocess the frame data. But I think it could be useful
in other cases.
I'm not sure that is sufficiently useful to bother with. I modelled the
two levels of interface on the other libdw interfaces, where dwarf_nextcu
deals in raw stuff without keeping state and everything else is higher-level.
- readelf cannot show eh_frame[_hdr] for binaries with separate
debuginfo files. This is somewhat inconvenient. binutils readelf
can show --debug-dump=frames in that case, but the elfutils readelf
output is nicer.
Fixed.
- gcc outputs an identical CIE over and over again. The .debug_frame
section of my vmlinux debuginfo image contains 1000+ identical CIEs.
Maybe gcc can be changed to keep track of CIEs it already created so
FDEs can all reference the same one.
I think it does that internally already. But you are looking at the
linked-together output of 1000+ translation units.
If not, it might be an easy target for the dwarf compressor.
I think ld already does this for .eh_frame (see bfd/elf-eh-frame.c),
but apparently it does not bother for .debug_frame.
The first few versions of DWARF compression will not think about CFI at
all. It is conveniently an entirely separate set of info from the DIE tree
where most of the space is taken. So it's really a completely separate
parallel bit of work. But indeed I had always imagined doing it eventually.
Thanks,
Roland