preliminary Linux ARM support

[crabtw]

It uses the private field of TCB head to store stack limit. I tested on my Raspberry PI. A simple hello world program ran without any problem. However, for a more complex program, it segfaulted as #6231.

[crabtw]

Here is a LLVM patch for segmented stacks
http://people.cs.nctu.edu.tw/~jyyou/rust/arm-segstk.patch

[luqmana]

Perhaps also add RUSTC_FLAGS_arm-unknown-linux-gnueabihf :=--linker $(CC_arm-unknown-linux-gnueabihf)

[crabtw]

added

[ILyoan]

Great!! but I'm not sure if it's safe to use 1'st TLS slot to store stack limit.
@crabtw Is it OK to use that slot?

[thestinger]

I don't think noexecstack is needed now that the assembly objects are marked as having non-executable stacks.

[luqmana]

@ILyoan@crabtw Currently and in this patch, the TLS base address is loaded via the system control coprocessor with mrc but on some ARM chips (like the one I was testing my patch on) that doesn't work so I loaded it instead from the magic address the linux kernel maps into processes, 0xFFFF0FF0. Would that perhaps be a more general approach?

[crabtw]

@ILyoan It's actually not a TLS slot. It's a private field of TCB. I am not sure if it is safe to use it.

typedef struct
{
dtv_t *dtv;
void *private;
} tcbhead_t;

From: http://www.eglibc.org/cgi-bin/viewvc.cgi/trunk/libc/ports/sysdeps/arm/nptl/tls.h?revision=22177&view=markup

[crabtw]

I removed -Wl,-znoexecstack

[crabtw]

@luqmana Loading from magic address is fine for me.

[brson]

I opened #6367 to batch up and merge our pending LLVM patches.