OSX support

[gilescope]

I've had a look at some of the alternatives of doing a stack walk on stack overflow and I want to try and see if I can use unwind-rs to achieve this.

Is anyone working on OSX support? Also for object loading should we use object crate or findshlibs - to my untrained eye they seem to do similar things.

I'm probably biting off more than I can chew, but rust has made me a bit more adventurous... any help / pointers on what I need to do to get it working on OSX much appreciated!

[philipc]

I haven't looked into this much, but I think that for unwinding you need to use something like findshlibs to find the call frame information that is already loaded into memory when the program is executed.

The object crate is useful for loading the DWARF debug info from the file for use in symbolication, but that's all already done by the addr2line crate (this is same as the hardliner crate in this git repo, which needs to be replaced with addr2line).

[main--]

Is anyone working on OSX support? Also for object loading should we use object crate or findshlibs - to my untrained eye they seem to do similar things.

As @philipc said findshlibs and this unwinder implementation read the in-memory call frame information of a running process (which is also subject to relocations etc) whereas the object crate reads information from a binary object (on disk).

findshlibs explicitly supports OSX, but I haven't gotten around to implementing this in unwind-rs. You would have to replace the implementation in find_cfi.rs with calls to findshlibs. The actual unwinding should ideally "just work", the code should be able to unwind any x86_64 SysV compatible platform - worst case you would need to adjust a few register mappings.

That being said, this crate is quite immature and not very well-tested so you may be better off with a libunwind-based solution like the unwind crate on crates.io (despite sharing the name, this is a different crate!).

[gilescope]

Thanks - I think I've just had a moment of clarity. To unwind a stack when you're on an alternative stack, even though you're in the same process you need to use the 'remote' unwinding method. Maybe. The problem I'm trying to solve is getting a nice backtrace when stack overflowing and thus the current thread is in an alternative signal stack. This is why I need to set a context other than the current threads context. With the findshlibs I've found the sections but turning seg.actual_virtual_memory_address(shlib) with seg.len() into a eh_frame_hdr The unwind crate looks like it would work if I could build the c++ libunwind library it depends upon, but I can't and pure rust is less dependencies and less things to go wrong.

[gilescope]

Still chipping away. I believe I have EhFrames now which is great. I can’t figure out where or if EhFrameHdr exist in mach-o? @fitzgen can you tell me, because the EhFrameHdr doesn’t look like a loader header. I’ve done macho-viewer on some execs and can’t see a __eh_frame_hdr or some such section either. Should I make EhFrameHdr optional? Or is it essential and I am just not looking in the right place for it?

[gilescope]

Finally found some decent documentation on eh_frame_hdr:
https://www.airs.com/blog/archives/462 and on eh_frame https://www.airs.com/blog/archives/460

I suspect we're not creating it by default on OS-X, but if its not added into the exec by the linker then there's nothing to stop us creating it at runtime. Just a speedbump...

[fitzgen]

@gilescope I don't believe that osx uses eh_frame_hdr. IIRC, it does have its own fast-path unwind section. I would recommend making eh_frame_hdr optional for now, and then look into the osx specific fast path stuff later.

[gilescope]

Ah yes the __unwind_info section with compact unwinding. For stacktracing when a stack overflow happens, performance isn't number one priority :-) . I will have a look - it looks like I've got all the pieces to manufacture a eh_frame_hdr from the FDEs so I'm going to shoot for the moon and try that. If that doesn't work then optional it is.

[gilescope]

Progress! I have a list of stack frames on OS-X :-) . That's as far as the unwinder is supposed to go. I'm going to try create an example using addr2line to dump the current stacktrace so that I can see if the addresses makes sense. The correctness test passes, but I note that under the hood backtrace::Backtrace::new_unresolved() goes to the unwind shim so it's helpful but it's not comparing against a completely different mechanism.