[PATCH] ARM + Thumb Segmented Stacks (v2)

[Alex Crichton]

Thanks for the response Oliver!

I've responded to your comments inline below, but I wanted to mention
that I don't think that this patch precludes fully using segmented
stacks just yet. We have had segmented stack code generation enabled
in LLVM for as long as I can remember in Rust. We have quite an
exhaustive test suite that is running on both x86 and ARM, so I
wouldn't call this addition useless waiting for more implementation.

I will agree, however, that it's not as 100% rock solid as what I
imagine gcc's x86 support for segmented stacks is. Many platforms
still aren't supported (only linux and android are currently
supported), and the Thumb support is fairly new and hasn't seen the
same coverage over time as ARM has. I'd love to help improve this
though!

> 1) Has the calling convention of __morestack for ARM been defined/documented anywhere?

Not that I know of, sadly. I'm also unaware of any documentation for
x86/x86-64. Do you know where I should put some small tidbits about
this documentation?

> Since rust has now abandoned segmented stacks

I may have mistakenly led you to believe this earlier, but we have not
abandoned the segmented stack prologue in rust. We've abandoned the
architectural part of segmented stacks that is segmented stacks
(ironic, yes?), but we are still using the prologue to detect stack
overflow. This is something we plan on changing, but we have no come
to a good conclusion on what it should change to.

This means that we currently have a __morestack implementation for ARM
[1]. This implementation doesn't allocate any more stack space, it
just jumps to a function which will abort (for various unrelated
reasons).

> 2) Is there currently an ARM implementation of __morestack? Rust's is dead.

Yes. Above I mentioned the current __morestack implementation, and you
can find the much older version (which actually did the segmented
stack bits) in the git history [2]. Just to clarify again, Rust's is
not dead, it's just not being used for what it was originally
intended.

> 3) You have not made any changes to the emission of DWARF info, so it seems unlikely that the DWARF stack frame info will accurately describe the stack layout. The emission of DWARF stack frame info may have been added to LLVM after rust forked it, but we cannot emit incorrect debug info.

I may be missing it, but it appears that x86 doesn't modify any such
DWARF info either? One of our debug-info tests [3] has a comment
saying that gdb breaks before the morestack prologue has run, so line
numbers are used.

I'm not super familiar with LLVM's DWARF support for stack frames
(sorry, I'm just trying my best to upstream the patch!), so could you
point me in the direction of what needs to be updated?

> 5) GCC can handle variadic functions for x86 and x86_64, and I can see no reason why we cannot do this on ARM. We should at least make sure that our definition of the interface to __morestack will not prevent adding this at a later date.

LLVM's currently implementation of segmented stacks for x86 does not
support varargs (so this ARM patch copies the same strategy). The GCC
docs for split stacks mention varargs functions, and the conclusion is
that they should basically be compiled differently to reference
arguments based on an arbitrary pointer rather than the frame pointer.

This sounds to me like it's the same __morestack interface, though,
where there's only one argument (the varargs pointer). This would
involve codegen changes for varargs functions which have split stacks
enabled to use this new pointer, however.

[1] - https://github.com/mozilla/rust/blob/master/src/rt/arch/arm/morestack.S
[2] - https://github.com/mozilla/rust/blob/86efd9/src/rt/arch/arm/morestack.S
[3] - https://github.com/mozilla/rust/blob/master/src/test/debug-info/function-arg-initialization.rs