Update libc to 0.2.24 #1

MaloJaffre · 2017-06-20T11:52:42Z

…crichton Allow atomic operations up to 32 bits The ARMv5te platform does not have instruction-level support for atomics, however the kernel provides [user space helpers] which can be used to perform atomic operations. When linked with `libgcc`, the atomic symbols needed by Rust will be provided, rather than CPU level intrinsics. [user space helpers]: https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt 32-bit versions of these kernel level helpers were introduced in Linux Kernel 2.6.12, and 64-bit version of these kernel level helpers were introduced in Linux Kernel 3.1. I have selected 32 bit versions as std currently only requires Linux version 2.6.18 and above as far as I am aware. As this target is specifically linux and gnueabi, it is reasonable to assume the Linux Kernel and libc will be available for the target. There is a large performance penalty, as we are not using CPU level intrinsics, however this penalty is likely preferable to not having the target at all. I have used this change in a custom target (along with xargo) to build std, as well as a number of higher level crates. ## Additional information For reference, here is what a a code snippet decompiles to: ```rust use std::sync::atomic::{AtomicIsize, Ordering}; #[no_mangle] pub extern fn foo(a: &AtomicIsize) -> isize { a.fetch_add(1, Ordering::SeqCst) } ``` ``` Disassembly of section .text.foo: 00000000 <foo>: 0: e92d4800 push {fp, lr} 4: e3a01001 mov r1, #1 8: ebfffffe bl 0 <__sync_fetch_and_add_4> c: e8bd8800 pop {fp, pc} ``` Which in turn is provided by `libgcc.a`, which has code which looks like this: ``` Disassembly of section .text: 00000000 <__sync_fetch_and_add_4>: 0: e92d40f8 push {r3, r4, r5, r6, r7, lr} 4: e1a05000 mov r5, r0 8: e1a07001 mov r7, r1 c: e59f6028 ldr r6, [pc, rust-lang#40] ; 3c <__sync_fetch_and_add_4+0x3c> 10: e5954000 ldr r4, [r5] 14: e1a02005 mov r2, r5 18: e1a00004 mov r0, r4 1c: e0841007 add r1, r4, r7 20: e1a0e00f mov lr, pc 24: e12fff16 bx r6 28: e3500000 cmp r0, #0 2c: 1afffff7 bne 10 <__sync_fetch_and_add_4+0x10> 30: e1a00004 mov r0, r4 34: e8bd40f8 pop {r3, r4, r5, r6, r7, lr} 38: e12fff1e bx lr 3c: ffff0fc0 .word 0xffff0fc0 ``` Where you can see the reference to `0xffff0fc0`, which is provided by the [user space helpers].

@michaelwoerister

…r=michaelwoerister Set the dwarf linkage_name to the mangled name ref rust-lang#46453 @michaelwoerister or anyone else who knows, i'm not sure if this is the correct instance to pass here (or how to get the correct one precisely): https://github.com//m4b/rust/blob/5a94a48678ec0a20ea6a63a783e63546bf9459b1/src/librustc_trans/debuginfo/namespace.rs#L36 So don't merge this yet, I'd like to learn about correct instance first; however, I think this already fixes a bunch of weirdness i'm seeing debugging from time to time, not to mention backtraces in gdb via `bt` are now ~readable~ meaningful 🎉 E.g.: new: ``` (gdb) bt #0 <inline::Foo as core::convert::From<()>>::from () at /home/m4b/tmp/bad_debug/inline.rs:11 #1 0x000055555555a35d in inline::deadbeef () at /home/m4b/tmp/bad_debug/inline.rs:16 rust-lang#2 0x000055555555a380 in inline::main () at /home/m4b/tmp/bad_debug/inline.rs:20 ``` old: ``` (gdb) bt #0 inline::{{impl}}::from () at /home/m4b/tmp/bad_debug/inline.rs:11 #1 0x000055555555b0ed in inline::deadbeef () at /home/m4b/tmp/bad_debug/inline.rs:16 rust-lang#2 0x000055555555b120 in inline::main () at /home/m4b/tmp/bad_debug/inline.rs:20 ```

Update libc to 0.2.24

174a7fc

Fixes rust-lang#42427.

MaloJaffre closed this Jun 22, 2017

MaloJaffre deleted the libc branch June 22, 2017 18:24

Repository owner locked and limited conversation to collaborators Aug 8, 2017

Repository owner unlocked this conversation Aug 8, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update libc to 0.2.24 #1

Update libc to 0.2.24 #1

MaloJaffre commented Jun 20, 2017

Update libc to 0.2.24 #1

Update libc to 0.2.24 #1

Conversation

MaloJaffre commented Jun 20, 2017