logs archiveBotHelp.net / Freenode / #3dsdev / 2015 / September / 17 / 1
furyhunter
realizing it will probably take a fair amount of std library implementation to make the rust runtime practical
I wonder how much of it is just implemented in libc functions
we have malloc on 3ds right
ok good rust's libc-based allocator will work
rust doesn't emit normal llvm-ir -_-
ahh fu*k it now I'm back to missing libcompiler-rt symbols
yuriks
furyhunter: *flips table*
furyhunter
every goddamn time
missing memcpy, memset, wtf... that's the issue I was having earlier with linking
WOW NO THIS IS THAT LINKER ISSUE
gotta disable unwinding in llvm somehow
OKAY WAIT I GOT IT
yuriks: it's that damn linker issue, I got unwinding disabled but fu*k it can't find memcpy and strlen and stuff like that, also the same symbols issue in libctru
but I do have a working libcompiler-rt.a with ALL the necessary symbols
(Action) cries softly
hmm, where are fake_heap_start/fake_heap_end ?
aliaspider
this probably ? https://github.com/devkitPro/buildscripts/blob/fdc132d7730b9ad4f0a63f38b967a8f4b4e638ce/dkarm-eabi/patches/newlib-2.2.0.patch#L6449
furyhunter
yep
okay yuriks cargo just built everything correctly
going to move around some code and see what happens...
it fu*king works. goddamn. it finally fu*king works.
sadagjkdjg;dsfg
profi200
Is your keyboard broken?
vaguerant
Only the home row.
furyhunter
yeah
i spent months on this stupid project and yay, it _actually_ works this time -- my safe layer over ctru-rs links everything correctly
profi200
What is the end goal? Providing a ruby compiler for thze 3DS?
furyhunter
rust, not ruby
profi200
Oops.
furyhunter
https://github.com/Furyhunter/rust3ds-template
okay, there it is
bit convoluted setup process...
profi200
Nice :)
archshift
furyhunter: awesome :D
furyhunter
http://www.idolagames.com/running-rust-code-on-the-3ds-2-electric-boogaloo/
profi200
The stack unwinding problem is where? With g++ if you enable rtti and exceptions it works fine.
You may however want to increase stack size.
furyhunter
llvm emit dependencies on unwind intrinsics that weren't available so my workaround was to just not do it >_>
(i.e. --release)
i can see stack size being a problem because there isn't Box yet, which means no heap allocations without unsafe calls to malloc/free
profi200
As temporary workaround you can increase the stack size to the entire heap.
furyhunter
wouldn't that break any C libraries
profi200
Hmm, well it could. So better leafve a bit of heap unused.
furyhunter
i think liballoc_system's only missing symbol on 3ds is posix_memalign, but I ran into some other linker issues with multiple definition
profi200
In C you can set the stack size with "u32 __stacksize__ = 0x40000;". It overrides the default (0x8000).
furyhunter
i guess that's just a symbol gcc looks for? easy enough to set in rust
actually it's pretty trivial to implement liballoc_system, i might just do it from scratch
http://github.com/rust-lang/rust/tree/master/src/liballoc_system/lib.rs
profi200
It's a weak field which get's replaced if you define it elsewhere.
https://github.com/smealum/ctrulib/blob/master/libctru/source/system/stack_adjust.s#L47-L49
You can't override it with a local variable however. It must be global.
yuriks: In that GPU code for mGBA can't you pass a pointer to a struct instead of passing more as 4 params? That's really inefficint :|
https://github.com/mgba-emu/mgba/commit/7d5dff4fc9737c1174f37fbe8313e6a553d47074#diff-87e19701767cf42186311ab04aefa7ceR348
That and other ones.
linkmauve1
furyhunter, you should use normal links instead of bit.ly ones, on your blog post.
profi200
*inefficient
xyz
why is it inefficient?
profi200
Because if you pass more as 4 params it throws them on the stack and load/store instructions are a lot slower as working with registers.
xyz
wouldn't it be the same thing with what you suggest
profi200
It would pass a struct and only load data if needed.
If you have more as 4 params they need to be stored on the stack and loaded again each call.
xyz
ah i see
yuriks
profi200: it would end up the same
xyz
i guess it will make a difference if you then pass these params to another function
furyhunter
yes! yes! I got alloc crate working
confirmed collections crate works, box works
iterators work, grabbing the framebuffer works
endrift
interesting, people are saying the CIA version of mGBA is faster than the 3dsx version on N3DS
profi200
That's bs. It is the same.
Did you not enable the L2 cache btw?
That would be better.
And because of the RomFS you don't need to worry anymore. That pull request fixed RomFS generation.
furyhunter
hmm! we can use https://github.com/AerialX/rust-rt-minimal for a libstd implementation because it rips out threads and unwinding
which is the primary concern
yuriks
furyhunter: what did you do to build this time?
furyhunter
not doing llvm-ir translation manually. I added a bunch of linker args frantically and it worked
also appending not prepending: https://github.com/Furyhunter/rust3ds-template/blob/master/3ds.json#L27
providing os: "linux" allows the sysroot crates to build correctly
i will push my modified build scripts for rustc that generate the working libcompiler-rt
but the one included in the repo works fine
yuriks
needs more -lsysbase
furyhunter
ahaha
soooo close to getting libstd though
ahh... that libstd doesn't compile bizarrely
bah, this rust-rt-minimal repo is too old
fml
the basic idea of getting libstd at this point is taking the matching rust libstd code for your rust version and applying a patch that replaces the unwinding and thread modules with dummies
yuriks
can't you just disable the winding with -Z no-landing-pads or something?
endrift
profi200: I can add that next
I was mostly just curious if the one change worked properly. Since it did, I can tweak it more.
furyhunter
yuriks: i'm already doing that sooo lol
https://github.com/Furyhunter/ctru-rs/blob/master/src/gfx.rs#L70-L123
yuriks
furyhunter: kek
oh, wait, you're wrapping, ok
I thought you had given up and reimplemented the functions in rust
furyhunter
no
« prev next »