Support iteration across eh_frame_hdr binary search table

[crzysdrs]

Allows for iteration across the binary search table entries found in the .eh_frame_hdr.

Closes #612

[philipc]

What do you need this for?

[crzysdrs]

The product I am currently working on does runtime manipulation of eh_frames, the binary search table and the corresponding headers. Traversal of the binary search table allows us to avoid unnecessarily visiting CIEs (which we aren't interested in) when modifying FDEs as well as verifying the correctness of any modifications to the table itself.

[philipc]

Are you modifying the binary search table too? It seems doing that would require duplicating some of this code. I'm not certain that an iterator is the best API for this sort of manipulation. Ideally you would operate on a slice of entries (although that might run into difficulties with supporting multiple pointer sizes).

[crzysdrs]

I agree that the iterator is not the most direct approach for manipulation but it is the most general for traversal. We are collecting data about the necessary modifications in the traversal and modifying out of band (since gimli isn't really a "modify in place" library). A slice does sound nice but it can't be a direct slice to memory due to the pointer parsing mechanics, so an interface would still have to sit between the two. It's worth noting that the iterator having the `nth` function implemented does allow for effectively random access when the size of entries is known which is almost as good as a slice.

…

On Thu, Apr 7, 2022 at 8:39 PM Philip Craig ***@***.***> wrote: Are you modifying the binary search table too? It seems doing that would require duplicating some of this code. I'm not certain that an iterator is the best API for this sort of manipulation. Ideally you would operate on a slice of entries. — Reply to this email directly, view it on GitHub <#619 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2OQ2EY2675GNHCV35BZ6TVD6S7TANCNFSM5S3DWBIA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Mitch