Can't compile "morestack.S" for iOS

[kud1ing]

The iOS/ARM toolchain does not know about the following Assembler directives:

• .fnend: marks the end of a function with an unwind table entry.
• .fnstart: marks the start of a function with an unwind table entry.
• .hidden: hides the symbol from other components.
• .movsp: tells the unwinder that reg contains an offset from the current stack pointer. (see compnerd/llvm@8da1908)
• .save: generates unwinder annotations to restore the registers.
• .setfp: makes all unwinder annotations relative to a frame pointer.
• .type: records the given type as the type attribute of a symbol table entry.

See https://sourceware.org/binutils/docs/as/ARM-Directives.html and http://www.informatik.uni-hamburg.de/RZ/software/gnu/gcc/as_7.html

Some directives are not implemented upstream yet: http://llvm.org/bugs/show_bug.cgi?id=18199

[brson]

llvm-mc might work

[alexcrichton]

No dice with LLVM sadly:

~/code/rust2[eintr] $ ./x86_64-apple-darwin/llvm/Release+Asserts/bin/llvm-mc -filetype=obj ./src/rt/arch/arm/morestack.S -triple=arm-apple-darwin
./src/rt/arch/arm/morestack.S:3:19: error: unexpected token in '.section' directive
.section        .note.GNU-stack, "", %progbits
                         ^
./src/rt/arch/arm/morestack.S:11:7: error: unknown token in expression
.align
      ^
./src/rt/arch/arm/morestack.S:15:1: error: unknown directive
.hidden __morestack
^
./src/rt/arch/arm/morestack.S:19:2: error: unknown directive
 .type __morestack,%function
 ^
Assertion failed: (TargetStreamer), function getTargetStreamer, file ../../../../../../src/llvm/include/llvm/MC/MCStreamer.h, line 173.
0  llvm-mc                  0x000000010f9e2ae8 llvm::sys::PrintStackTrace(__sFILE*) + 40
1  llvm-mc                  0x000000010f9e2fe4 SignalHandler(int) + 548
2  libsystem_platform.dylib 0x00007fff87b005aa _sigtramp + 26
3  libsystem_platform.dylib 000000000000000000 _sigtramp + 2018507376
4  llvm-mc                  0x000000010f9e2da6 abort + 22
5  llvm-mc                  0x000000010f9e2d81 __assert_rtn + 81
6  llvm-mc                  0x000000010f8aa302 (anonymous namespace)::ARMAsmParser::ParseDirective(llvm::AsmToken) + 10834
7  llvm-mc                  0x000000010f92b4e3 (anonymous namespace)::AsmParser::parseStatement((anonymous namespace)::ParseStatementInfo&) + 2083
8  llvm-mc                  0x000000010f927407 (anonymous namespace)::AsmParser::Run(bool, bool) + 439
9  llvm-mc                  0x000000010f848053 main + 4275
10 libdyld.dylib            0x00007fff885be5fd start + 1
Stack dump:
0.      Program arguments: ./x86_64-apple-darwin/llvm/Release+Asserts/bin/llvm-mc -filetype=obj ./src/rt/arch/arm/morestack.S -triple=arm-apple-darwin 
zsh: illegal hardware instruction (core dumped)  ./x86_64-apple-darwin/llvm/Release+Asserts/bin/llvm-mc -filetype=obj  

[kud1ing]

Hm, the errors persist:

src/rt/arch/arm/morestack.S:40:5: error: unknown directive
    .fnen

The strange thing is, when you grep for .fnend in our LLVM tree, there is some ARM-related code for/using .fnend.

[kud1ing]

Ah ok, we use the system clang:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Wall -Werror -g -fPIC -target arm-apple-darwin -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/c++/4.2.1 -MMD -MP -MT arm-apple-darwin/rt/arch/arm/morestack.o -MF arm-apple-darwin/rt/arch/arm/morestack.d /Users/lenny/Code/GitHub/Rust/src/rt/arch/arm/morestack.S -c -o arm-apple-darwin/rt/arch/arm/morestack.o

Can we build and use our own Clang?

[alexcrichton]

Bundling our own snapshot of clang would fix various other problems, but it's a significant undertaking that would make package managers even more unhappy with us than they already are. It does seem that we're moving in that direction though, it probably just won't happen overnight.

I think a good solution to this would be to use llvm-mc because we'll almost always be building that. We just need to figure out the right flavor of directives that don't regress behavior but also don't cause llvm to explode when compiling. I'm not sure what any of these directives are, but they may not all be necessary if we know the exact assembler that we're using perhaps?

[kud1ing]

I'm not sure what any of these directives are, but they may not all be necessary if we know the exact assembler that we're using perhaps?

They are described in one of the links above: https://sourceware.org/binutils/docs/as/ARM-Directives.html

I neither do know much about ARM assembler nor about morestack.
Is there any domain expert's knowledge we could tap?

[bharrisau]

The full story:

The segmented stack prolog calls __morestack(StackSize, Size of stack arguments). LLVM expects morestack to allocate more stack, fix up the two registers used for (StackSize, Size of stack arguments) then call into the [return_address + X], which is actually the function body. When the function returns, morestack shrinks the stack then returns from the original function call.

In our world, morestack ignores the two arguments and calls rust_stack_exhausted() which increases the stack limit a little, prints an error, then aborts (ideally unwinds in the future).

Given that rust_stack_exhausted() aborts, for the ARM case we could drop morestack.S and just add a function to libstd

#[no_mangle] 
#[no_split_stack]
pub extern "C" fn __morestack() { rust_stack_exhausted() }

[alexcrichton]

That sounds like a correct summary to me, but I don't think that defining __morestack as a regular function will work because __morestack gets called with a misaligned stack. The assembly we currently have must re-align the stack before calling the rust_stack_exhausted function.

[bharrisau]

Are you sure it still does that on ARM? I know it's an issue on x86, but
from a casual look the ARM code only has the info for unwinding then the
branch op.
On 14/03/2014 3:27 pm, "Alex Crichton" [email protected] wrote:

That sounds like a correct summary to me, but I don't think that defining
__morestack as a regular function will work because __morestack gets
called with a misaligned stack. The assembly we currently have must
re-align the stack before calling the rust_stack_exhausted function.

Reply to this email directly or view it on GitHubhttps://github.com//issues/11312#issuecomment-37622552
.

[alexcrichton]

I know for certain that the arm prelude causes an unaligned stack because the upstream LLVM folks are worried about it (I'm trying to upstream it)

[kud1ing]

Likely fixed by #14715