Use upstream gimli - Githubissues

gimli-rs / unwind-rs

Apache License 2.0

26 stars 10 forks source link

Closed roblabla closed 5 years ago

roblabla commented 6 years ago

unwind-rs uses a fork of gimli, which makes the private parse_cfi_entry public and parses (but ultimately ignores) DW_CFA_GNU_args_size.

We should strive to use upstream gimli.

Path forward:

Instead of parse_cfi_entry, maybe we should add an UnwindSection::fde_from_offset (the equivalent to UnwindSection::cie_from_offset and use that ?
What needs to be done to upstream DW_CFA_GNU_args_size ? Most implementation I've seen seem to simply ignore it.

main-- commented 6 years ago

We should strive to use upstream gimli.

I agree.

From what I remember, the the main problem there was not just exposing a function to access an FDE but rather the fact that the lookup goes through eh_frame_hdr which usually straight up references an entirely different segment of the binary. The critical part here is the slice_from_raw_parts - note how the length is completely bogus as we only get a pointer from eh_frame_hdr without any length. That‘s why I initially just punted on this.
DW_CFA_GNU_args_size appeared in some of my test binaries so I quickly patched it in. I don‘t think it requires much special handling, ignoring it seems like the correct approach.

kitlith commented 5 years ago

This is resolved as of #17 and should be closed, right?

philipc commented 5 years ago

Yes, thanks. Note that the next release of gimli will have breaking changes that affect this crate (Register and BaseAddresses).