Sections in segment: merge from master

[gilescope]

I've implemented unsupported EhFrame and EhFrameHdr types as unsupported wasn't in the branch. The rest pretty much merged fine.

[philipc]

Can you rebase so that it's only the new commits in the PR?

[philipc]

Oh, I see this is a PR against the sections-in-segment branch, is that what you intended?

[gilescope]

Yes, just bring that branch up to date. I need to review the linux builds as something is clearly not happy.

…

On Sun, 5 Aug 2018 at 10:06, Philip Craig ***@***.***> wrote: Oh, I see this is a PR against the sections-in-segment branch, is that what you intended? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAxEiG2lq6iH4mLVNSVtmY3yomw9Imwcks5uNrV_gaJpZM4VvTDD> .

[philipc]

Yes, just bring that branch up to date.

Ok. I think it's better to rebase and create your own branch instead. I prefer if the final PR against master doesn't have merge commits in it.

I need to review the linux builds as something is clearly not happy.

The EhFrame trait is hard/impossible to implement on linux, so that'll be one reason why @fitzgen never merged this to master. Note that this inability to find eh_frame is also the reason for this hack in unwind-rs.

For linux, I have an idea that since eh_frame_hdr tells us where eh_frame starts, maybe we can use that to find the segment containing eh_frame, and deduce the length from that. I'll look into this later.

[philipc]

gimli-rs/unwind-rs#18 shows what I was meaning for finding eh_frame, although it's not as good as I wanted.