cfi branch

[Roland McGrath <roland at redhat dot com>]

In working on the relocate branch I thought about relocation-aware
interfaces for CFI, since that is one of the remaining holes there.
The only interface for actual decoding we have is dwarf_addrframe.

That doesn't make much sense with unresolved relocatable addresses.
Actually it could make sense to search for a Dwarf_Relocatable, in
the same sense that dwarf_haspc_relocatable does.  So we might add
that at some point.

But it got me thinking that the only thing you'd really want to do
that makes sense is to iterate through all the frame states, where
the PC bounds of each state can be described in relocatable form.
I'd just mentioned this kind of iterator in the other thread with
Mark.  But I had been thinking it would be significant work to add an
interface for that.  It turns out it's not really.

So I made the roland/cfi branch forked from the trunk.  This adds a
dwarf_cfi_frames call that iterates through the frame states.  I
haven't tested it at all, but I think it's more or less sound, and it
was easy to do.  I did this separate from the relocate branch because
I was thinking it could be merged in independently.  It can, but I'm
doubtful there will be any use of this interface soon enough to want
to bake it before we want to merge relocate anyway.

I did merge the cfi branch into the relocate branch.  So if I follow
through with CFI relocatability, dwarf_cfi_frames will work with that.
With that iterator, we can add the relocatability support under the
covers of Dwarf_Frame (as for Dwarf_Line).  Then it just needs a
dwarf_frame_relocatable call that parallels dwarf_frame_info.
And we can consider adding dwarf_cfi_addrframe_relocatable for lookup.

All of that is probably only really useful when we have something for
it to feed.  We could give readelf a decoded-frame printer, perhaps.
On the pipe-dream list remains the smart disassembler, which would
generate a stream of DWARF locations and expressions that a CFI
checker would match up with Dwarf_Frame register locations.  Another
nice thought is a CFI generator from whole cloth, so we could
"compress" and consolidate by feeding it streams from .eh_frame and
.debug_frame input and generate our own smallest-encoded CFI with that
meaning.  But those are not things that will happen soon.  So it is
hard to justify any new APIs about this going onto the trunk in the
foreseeable.


Thanks,
Roland