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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
