Re: [rust-dev] Problems cross-compiling to ARM9
Hi Tomi, > The prologue problem was fixed by adding "morestack: false," to the > linux ARM target specification, similar to how it is in the iOS > target. Right, my bad, that should be enough. > My device does not really benefit from the segmented stack, since it > has only 64MB RAM Segmented stacks in Rust for a long time are used only for catching a stack overflow. -- Valerii signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Tools for auto-extracting FFI for C libraries?
Hi Tom, > Is anyone aware of work on a tool to automatically generate an FFI > for C libraries? https://github.com/crabtw/rust-bindgen -- Valerii signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Problems cross-compiling to ARM9
Hi Tomi, > Anyone have any idea if that's a larger problem, or simply something > nobody has written the small handcoded ASMs needed for ARMv5 or v4? > If latter, I might be able to wrap my head around this. The problem you've got is related to segmented stack support. It need fix on 2 levels: - Rust - can be relatively easy fixed by providing (or patching) a target and marking it as a target which doesn't support segmented stacks, see example [1] Once it works you can play a bit to provide a correct implementation in record_sp.S and morestack.S - LLVM - as I remember some time ago LLVM generated a function prologue which uses the same instruction for any ARM device, may be that was patched in upstream, may be not. You can also ask Vladimir Pouzanov and zinc.rs [2] team, AFAIK they had the similar problem too and definitely have a workaround. [1] https://github.com/rust-lang/rust/blob/master/src/librustc_back/target/arm_apple_ios.rs#L33 [2] https://zinc.rs/ -- Valerii signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] target json documentation
Hi Kashyap, > I've used it here - > https://github.com/ckkashyap/unix/blob/master/kernel/Makefile and it > appears that the compiler does honor the contents of the json file > that is passed. Corey Richardson can help you with that. -- Valerii signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] [ANN] Rust ported to DragonFlyBSD
Hi, > Also when using the --target approach, I always had to wait for hours > until it finished the Linux (host) build before it started to build > the target. Yep, `--target` approach can be extremely exhausting. One pretty useful dirty trick in this case is to build it once for host and play a lot with `touch -r`. It might be used to recompile only for target when you have changes in mk/* or src/lib*. For example, if you've changed src/libstd/somefile.rs, you can later on do: `touch -r src/libstd/lib.rs src/libstd/somefile.rs` If libstd was compiled successfully before it is required also to delete stamp: `rm build_dir/host_triple/stage2/lib/rustlib/target_triple/lib/stamp.std` and `make -j4` it again, just for target, no waiting for host :-) Used it a lot while porting for iOS and while this message is definitely late for Dragonfly - I hope it will be useful for others who might be interested in porting to platforms which are easier accessible through `--target` approach. -- Valerii signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] adding a new cross-compile target
Hi Rob, > make: *** No rule to make target > `powerpc64-bgq-linux/rt/arch/powerpc64/morestack.o', needed by > `powerpc64-bgq-linux/rt/libsmorestack.a'. Stop. > > I don't know how to go about debugging this. Any ideas? There is no way to "debug" this - you have to implement a couple of functions which are required by Rust runtime and are architecture-dependent. They live in src/rt/arch/$ARCH_NAME$ Functions (files) are: morestack (morestack.S) - it is a vestige from segmented stack time. Back then it allocated a new stack segment once were wasn't enough space in the current one. Nowadays it just calls rust_stack_exhausted function. record_sp_limit (record_sp.S) - should store stack limit for current task (usually it uses platform specific thread local storage). get_sp_limit (record_sp.S) - should return stack limit for current task (reads from the same platform-specific thread local storage) rust_swap_registers (_context.S) - I'm not sure about this one, but I assume it allows correct register restoration in case of green task switches. rust_bootstrap_green_task (_context.S) - again, not sure, but I assume it initializes green task. Note, that all stack-related functions (morestack, record_sp_limit, get_sp_limit) should be actually compatible with LLVM segmented stack prologue (in your case consult $LLVM/lib/target/PowerPC/PPCFrameLowering.cpp, emitPrologue and emitEpilogue methods, may be a couple of others). For a reference implementations (and much more additional comments) see src/rt/arch/i386/*.S -- Valerii signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] 0.11.0 prerelease testing
Hi Alex, > The source also supports a number of other platforms such as Android and > iOS now. Unfortunately iOS build is failing now because of LLVM bug and as patch for it hasn't yet landed, I believe it shouldn't be mentioned in release notes. -- Valerii signature.asc Description: OpenPGP digital signature ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] iOS cross compilation
Hi, So finally Rust can cross-compile for iOS (armv7 only for now). BTW, it also means that Rust now can be used both for iOS and Android low-level development. Short instructions are available here: https://github.com/mozilla/rust/wiki/Doc-building-for-ios Unfortunately LLVM patch for supporting segmented stacks on armv7 was declined by Apple (it used kind of private API) and therefore there is no stack protection at all. It still could be enabled by compiling with a patched LLVM (I can provide a patch and instructions if needed). Everything else should "just work" but let me know if you have any problem. -- Valerii ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Nightly docs for Dash
Hi Vladimir, > It removes the left side navigation panel from docs and adds TOC generation. Looks nice, I've added TOC generation too (so far I'm not using dash-rust and plan to publish the code after cleaning up a bit). One of the reason is that dash-rust actually shows much more information than actually available, for example, if you open Fields section there is alloc::rc::Rc::_noshare, alloc::rc::Rc::_nosend, alloc::rc::Rc::_ptr . All of them are actually private fields and aren't visible in the struct doc. It looks more like rustdoc problem, but still. My method of generating is more fragile to changes (as it actually processes html) but funnily enough it is faster than using precompiled JS indexes. Although it might be misconfiguration on my side if there is requirement to install some additional libraries. -- Valerii ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Nightly docs for Dash
Hi, Being a big fan of offline documentation I've prepared a fresh docset for Dash (zeal, helm-dash, any other compatible software). Here is the link for subscription: dash-feed://https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fnet.vhbit.rust-doc%2FRustNightly.xml It's a beta and has a couple of known issues in it. If there would be enough interest - it could be also integrated with existing buildbots. -- Valerii ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How do I bootstrap rust form armhf?
I'm trying to run rustc on an arm board, but obviously there's no precompiled stage0 to build the compiler. Is there a procedure to cross-compile stage0 on other host machine where I do have rustc? Disclaimer: haven't tried anything like this, but just a couple of hints: - configure script checks for CFG_ENABLE_LOCAL_RUST, so it should be possible to use any rustc - in src/etc there are make_snapshot.py, snapshot.py, local_stage0.sh which might be useful for study - there are a couple of mentions of cfg(stage0) in sources, probably compiling rust for stage0 will require additionally setting --cfg stage0 -- Valerii ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] *c_char and *c_uchar
Hi Christophe,
> i can not use :
> let ppDb : **mut () = RawPtr::null();
> unsafe { res=sqlite3_open(filename.as_ptr(), ppDb);
> because as_ptr() returns an *u8 and c_char is a i8, so i have to use
> extern { fn sqlite3_open(filename: *c_uchar, ppDb : **mut ()) ->
> c_int; }
as_ptr() is a bad idea as there is no guarantee that Rust string is
null-terminated. It should be safer to use with_c_str like:
filename.with_c_str(|c_str| unsafe {
sqlite3_open(c_str, ppDb)
})
More details here:
http://static.rust-lang.org/doc/master/std/c_str/trait.ToCStr.html#method.with_c_str
> Now, suppose i use
> extern { fn sqlite3_errmsg(pDb : *mut ()) -> *c_uchar; }
I believe it actually should be
extern { fn sqlite3_errmsg(pDB: *mut()) -> *c_char; }
And for creating an owned string from it you can use
std::str::raw::from_c_str
More details here:
http://static.rust-lang.org/doc/master/std/str/raw/fn.from_c_str.html
--
Valerii
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Once_fns
I apologize for sending draft, here goes the full version. Which is current state of once functions? In the doc https://github.com/mozilla/rust/wiki/Doc-under-construction-FAQthey are mentioned as experimental feature, which might not be enabled in 1.0. Compiler shows a warning "once functions are experimental and likely to be removed", which raises question "how likely" considering wiki page was last edited 9 months ago. Is better to avoid them at all or it's still safe use them as experimental feature? -- Valerii On Thu, May 1, 2014 at 11:15 AM, Valerii Hiora wrote: > Hi, > > Which is current state of once functions? > In the doc > https://github.com/mozilla/rust/wiki/Doc-under-construction-FAQ it > mentioned as experimental feature, which might not be enabled in 1.0. But > it is > Compiler shows a warning > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Once_fns
Hi, Which is current state of once functions? In the doc https://github.com/mozilla/rust/wiki/Doc-under-construction-FAQit mentioned as experimental feature, which might not be enabled in 1.0. But it is Compiler shows a warning ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
