Add control flow information to __rust_probestack

[tmandry]

This adds control flow information (CFI) on x86 and x86_64 platforms, so that DWARF-based backtraces work when the stack probe fails.

The implementation builds on the work done in #305 and #306. It manages to keep the CFI in inline assembly by defining a "function within a function." This has been done elsewhere; see e.g. this LibFuzzer code.

[tmandry]

Unfortunately the mach-o assembler doesn't support the directives I'm using to keep the assembly inline. I don't know how to express what I want to in that assembler (it doesn't like some of the assembly used in #305 either).

That means we'll have to split the implementations for Mac out :(

[tmandry]

Actually, it seems #305's implementation did compile on apple except for the .type __rust_probestack, @function directive. I'm not sure what the implication would be of removing it, but if we can do that then it's probably best to go with that approach (which would require using external assembly files).

There doesn't seem to be any substitute for .pushsection/.popsection in Apple's assembler, and I don't know how to keep the assembly inline without those.

EDIT: I actually think there's still a way of doing it inline, so I'll play with that.

[tmandry]

Hmm, so wrapping our inner implementation in .cfi_endproc/.cfi_startproc is required in debug builds, but fails in release builds. Not doing this succeeds in release builds, but fails in debug builds.

It seems like the enclosing .cfi_startproc/.cfi_endproc of __rust_probestack_wrapper gets "optimized out" in release builds. Not sure what to do about this yet.

[bjorn3]

I believe on Mach-O the linker would be allowed to move this symbol and following content to another location, as it uses symbols to determine the start and end of every function.

[tmandry]

I think that would be fine. __rust_probestack is the function that gets called, not __rust_probestack_wrapper.

[bjorn3]

Maybe use global_asm! instead of inline asm?

[tmandry]

Maybe use global_asm! instead of inline asm?

I didn't know about global_asm!, thanks! Hopefully that can get me out of this startproc/endproc mess.

[alexcrichton]

Now that's an impressive set of green :)

I think it'd be good to hook this up into rust-lang/rust before merging though (via [patch] most likely). Would you be ok running the test suite locally with this merged into make sure it's all still working at least at a high level?

[tmandry]

Done! Had to make one change, now all tests pass on both linux and mac.

[alexcrichton]

👍