ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
Makarov has quit [Quit: Client closed]
nadja has quit [Ping timeout: 265 seconds]
nadja has joined #rust-embedded
ello has quit [Quit: ZNC 1.9.1 - https://znc.in]
ello has joined #rust-embedded
GuineaWheek[m] has joined #rust-embedded
<GuineaWheek[m]> is there a way to read_volatile a variable-length slice
<GuineaWheek[m]> i know there was some nightly-gated stuff that could do it
<Lumpio-> read_volatile in a loop
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
korken89[m] has joined #rust-embedded
<korken89[m]> Maybe someone else is also compiling embedded Rust projects on an ARM device, has anyone run into the following error and solved it?... (full message at <https://catircservices.org/_irc/v1/media/download/ATwnuEn1T0_PCHT0jfINjck41R6e4Lrw2tOX8RE83E02dNpE3fccU9kVjOQw1O9qsJoYNisYQOYQgjnRXIPFmFJCeSYQ6oEwAGNhdGlyY3NlcnZpY2VzLm9yZy9nRmJSeW5EbEp1Y1BkYkRkVG1KVU9hQ0Y>)
<korken89[m]> s/```//, s///
<korken89[m]> Indeed it does specify -C linker=aarch64-linux-gnu-gcc, but I don't understand why
jannic[m] has joined #rust-embedded
<jannic[m]> That's while building build.rs, right?
<dirbaio[m]> Check you have nothing overriding the linker for "all ARM", I've seen some examples/templates do that to set the linker for the embedded target, assuming the host is x86
<dirbaio[m]> Hmm but that wouldn't set it to the aarch64-linux one
<dirbaio[m]> Maybe you have some .cargo/config.toml in some parent folder affecting things?
<jannic[m]> I tried it out on a freshly installed aarch64-unknown-linux-gnu vserver: I don't see -C linker=aarch64-linux-gnu-gcc in any of the rustc invocations.
<jannic[m]> That was on ubuntu 24.04, rust installed using rustup.
haobogu[m] has joined #rust-embedded
<haobogu[m]> Hey there's a question about embassy-executor: according to https://docs.embassy.dev/embassy-executor/git/cortex-m/index.html#statically-allocating-tasks , if I enable nightly feature, and make a task like #[embassy_executor::task(pool_size=32)], then the actual mem usage is calculate at compile-time statically, am i right?
<haobogu[m]> If I spawn only 1 task in my code, does it take 32*task memory usage as well?
<JamesMunns[m]> you will statically reserve space for 32 tasks, and if you only spawn one task, there will be 31x "unused" memory chunks
<haobogu[m]> gotcha, thanks!
<dirbaio[m]> <haobogu[m]> "Hey there's a question about ..." <- yes
<dirbaio[m]> it'll show up in size in .bss
<dirbaio[m]> <haobogu[m]> "If I spawn only 1 task in my..." <- yes, it'll reserve space for 12 copies of the task and use only one.
<dirbaio[m]> s/12/32/
<thejpster[m]> ping on https://github.com/rust-embedded-community/embedded-sdmmc-rs/pull/143 - I put a RefCell in my SD Card library so it's easier to have multiple files open, but there's a higher risk of run-time crashes due to lock contention.
<thejpster[m]> also, I think the issue with infinite recursion in compiler-builtins might have been fixed - although most people probably didn't notice as it only seemed to affect SPARC and WASM, and maybe other CPUs that don't have hardware multipliers.
<thejpster[m]> (I think I need a new computer - repeatedly rebuilding rustc on a 10 year old quad-core Core-i5 4590 is starting to get me down)
cbjamo[m] has quit [Quit: Idle timeout reached: 172800s]
<korken89[m]> <dirbaio[m]> "Maybe you have some .cargo/..." <- I'm going to search more :)
<korken89[m]> I just got Linux running on my Snapdragon X based laptop, so I guess this is quite uncharted territory. 😅 The interesting thing is that it builds fine on x86 so I think you are right about something overriding all ARM.
<i509vcb[m]> korken89[m]: That's a weird error since I've been able to build stuff fine on aarch64 Linux
<korken89[m]> Yeah, I'm quite confused tbh
<korken89[m]> Maybe it's NixOS related as well
<i509vcb[m]> Yeah I'd probably think NixOS is the first place I'd check
<i509vcb[m]> Everything builds fine on Fedora for me
<korken89[m]> It's also only this one project that had issues. I devved on the rysty probe for hours without issues. Something is sneaky
<dirbaio[m]> Nixos is well known for resulting in broken rust installs :D
<korken89[m]> s/rysty/rusty/
<korken89[m]> Oh noes 😅
<dirbaio[m]> You installed it from rustup, at least?
<korken89[m]> Yeah
<korken89[m]> Worst case it's just to remove crate after crate in the repo until one hits the truth
<dirbaio[m]> Check you don't have any config
<dirbaio[m]> Either .cargo/config.toml or these env ars
<dirbaio[m]> s/env ars/envvars/
<korken89[m]> Right, if something is hiding. I'll start digging, thanks!
<korken89[m]> <dirbaio[m]> "Either .cargo/config.toml or..." <- You, my man, are a genius 🎉 Looooong ago we had a M1 Mac dev in the project, it was one of his files that were hunting me with:... (full message at <https://catircservices.org/_irc/v1/media/download/AephUuCl01ccmYsVlzRQGuDPv2GOC4u4_UnoyZp0A3ZG_Hoevi41VJKnv302Rf0jKd8oIemPKLkjjJHIQa-Q4RxCeSY0Hb2AAGNhdGlyY3NlcnZpY2VzLm9yZy9vd1JOd2pBUGZUZ0FiZ3FXbnBRTlRSZ3U>)
<korken89[m]> s/hunting/haunting/
<korken89[m]> Also TIL rg -uuu
vancz has quit []
vancz has joined #rust-embedded
omani[m] has joined #rust-embedded
<omani[m]> Im trying to use ripemd160 from here https://docs.rs/ripemd/0.1.3/ripemd/
<omani[m]> but I have no associated Ripemd160::new() function like shown in the example. any hints?
<JamesMunns[m]> are you importing the Digest trait? https://docs.rs/ripemd/0.1.3/ripemd/trait.Digest.html
<JamesMunns[m]> Traits need to be imported in-scope to be able to use their methods on types that implement them
<omani[m]> yes. do I need to add digest as a dependency? I didnt because they depend on it already.
<JamesMunns[m]> do you have exactly that in your code?
<omani[m]> yes
<omani[m]> std feature per default.
<JamesMunns[m]> can you put your code up in a gist or github repo?
<dirbaio[m]> hashing bitcoin addresses? :P
<JamesMunns[m]> you don't just need to import the crate, you need to import the trait in the rust file
<JamesMunns[m]> And yeah, for what it's worth, this room is for embedded systems, like microcontrollers. #rust:matrix.org is I think a general Rust room.
<omani[m]> even though with `Digest` the `new()` function is available. I guess rust-analyzer is tripping.
<omani[m]> thanks.
<omani[m]> worth noting that there is an issue for this: https://github.com/RustCrypto/hashes/issues/529
<omani[m]> ^ btw `rustup update` fixed this for me.
<omani[m]> * for me. with a new version of rust-analyzer.
huayra1[m] has joined #rust-embedded
<huayra1[m]> i really, *really* want rust in my kernel that i am developing. it's a fork of xv6 that i have worked in for months. it has DLang support because it was seamless, but i have tried like 4 times to integrate rust, to no avail. my requirements:
<huayra1[m]> - no rustup
<huayra1[m]> - (preferrably) no nightly features
<huayra1[m]> i can work my way up from a wrapper around C
<huayra1[m]> * i really, really want rust in my kernel that i am developing. it's a fork of xv6 that i have worked in for months. it has DLang support because it was seamless, but i have tried like 4 times to... (full message at <https://catircservices.org/_irc/v1/media/download/ASb49hXvqG4EKVMyCb8b_kWW4onwqaN1BTCUJd0MIix9-X5WBTIBVfZvEVTS5Lk9y-yEUyJIRni-VPjYq6uMH_JCeSZFGEGQAGNhdGlyY3NlcnZpY2VzLm9yZy9qcGtzVERRallkUExZckdqaGNhYmxzSWc>)
<huayra1[m]> yes
nandnor[m] has joined #rust-embedded
<nandnor[m]> No nightly will be tough. Do you have any variadic functions?
<nandnor[m]> OK then you need nightly atm
<huayra1[m]> printf, sprintf
<huayra1[m]> pretend they don't exist for a moment
<huayra1[m]> i need to compile code for i686 baremetal. can i do this with x86_64 linux toolchain?
<JamesMunns[m]> Have you seen https://os.phil-opp.com/ before, btw?
<nandnor[m]> OK if you can get rid of all of your variadic functions then thats one step closer (btw this is the feature I am talking about that requires nightly #![feature(c_variadic)] ) but probably other roadblocks as well
<JamesMunns[m]> it covers a lot of this
<huayra1[m]> JamesMunns[m]: yes but it jumps right into rustup
<huayra1[m]> if my toolchain can compile i686, it should.
<JamesMunns[m]> wait, why no rustup? It's a nice tool.
<huayra1[m]> the downstream users would need it
<huayra1[m]> and it fetches a lot of internet stuff for a toolchain for every user
<JamesMunns[m]> if they are compiling the kernel?
<huayra1[m]> xv6 is pretty inseperable from the kernel
<JamesMunns[m]> I mean, maybe I just don't track the planned use case. You can always make your own toolchain distribution or whatever, it's just generally not pleasant.
<huayra1[m]> rxv64 doesn't compile on modern rust toolchains either
<JamesMunns[m]> gotcha, maybe just suggesting you could use rustup until you have it working, then package your own toolchain with deps pre-vendored I guess?
<JamesMunns[m]> dunno how far along you are with your integration work.
<huayra1[m]> added only a few thousand lines to it
<JamesMunns[m]> (rustup supports adding custom built toolchains as well)
<huayra1[m]> it's not a production thing or anything but anyone even merely wanting to test it already needs: c compiler, d compiler, linker, qemu, ar, ranlib, gmake, and now a 500mb download that is guaranteed to be needed
<huayra1[m]> nobody casually has an i686-unknown-elf target lying around on their machine
<JamesMunns[m]> I suppose you know your user's need better than I do!
<JamesMunns[m]> Sounds like an interesting challenge.
<huayra1[m]> not to mention support for i686 rustup targets seems to be limited: no nightly and no "complete" toolchain, just "minimal".
<dirbaio[m]> rustc can compile for any supported target, always
<huayra1[m]> would you like to see the project perhaps?
<huayra1[m]> dirbaio[m]: through *what* flag? --target?
<dirbaio[m]> --target, yep
<dirbaio[m]> popular targets include a prebuilt stdlib shipped through rustup.
<dirbaio[m]> less popular targets don't, in that case you have to build the stdlib yourself. Cargo has builtin support for this, it requires just adding the -Zbuild-std flag.
<dirbaio[m]> and if you define your own target json you have to, as well
<huayra1[m]> notice no unknown-elf. the other ones assume glibc
<huayra1[m]> dirbaio[m]: does this not require rustup then?
<dirbaio[m]> there's 2 things here
<dirbaio[m]> - how you get rustc installed (either from rustup, or from your distro's package manager, or from source)
<dirbaio[m]> - how do you get that rustc to build for i686=none
<dirbaio[m]> they're completely independent
<dirbaio[m]> any rustup (no matter how you've installed it) is capable of building for i686
<dirbaio[m]> s/rustup/rustc/
<huayra1[m]> rustc is installed from the package manager
<dirbaio[m]> how you do step 1 doesn't affect how you do step 2
<huayra1[m]> i know
<huayra1[m]> but if the target mentions musl it would assume musl exists
<dirbaio[m]> yeah
<dirbaio[m]> you have to make your own target from scratch
<dirbaio[m]> rustc -Zunstable-options --print target-spec-json --target i686-unknown-linux-gnu
<huayra1[m]> the elf target assumes less but it seems to only be available for x86_64
<dirbaio[m]> save that to i686-unknown-none.json
<dirbaio[m]> edit it as you need
<dirbaio[m]> * save that to i686-unknown-none-elf.json (or whatever name you want)
<dirbaio[m]> for example you can pick i686-unknown-linux-gnu as a starting point
<dirbaio[m]> then remove all the things specific to linux
<dirbaio[m]> you can also try printing the x86_64-unknown-none target, to see how a bare-metal target json looks like
<dirbaio[m]> hopefully by "mixing" them you can get a working i686-unknown-none.json
<dirbaio[m]> and then you can build using it with --target i686-unknown-none.json
<dirbaio[m]> dunno if the json there will work, the target jsons typically need some updates as you update rustc
<JamesMunns[m]> There are a couple xv6 rust projects btw
<JamesMunns[m]> https://github.com/Ko-oK-OS/xv6-rust is one I saw recently
<huayra1[m]> ahhh i see
<huayra1[m]> i will try this
<JamesMunns[m]> JamesMunns[m]: (Im just realizing that most of the ones I've seen target either x86_64 or riscv, not i686)
<huayra1[m]> ...and now we wait for rust to compile (gentoo)
<huayra1[m]> speaking of which, compile time is a huge part of it for me. right now, my version of xv6 builds in 1 second on my laptop
<dirbaio[m]> use rustup lol
<huayra1[m]> that still doesn't fix rust's build times of code in its language
<huayra1[m]> rust is excusable because of safety, C++ would be insane to add due to its compile time and unsafety.
<huayra1[m]> dlang with dmd is actually faster to compile than C through gcc's O0
<JamesMunns[m]> tbh build times in rust are generally very fast, unless you have hundreds of deps
<dirbaio[m]> "rust is slow to compile" is a myth
<JamesMunns[m]> which is rare for embedded or microkernels
<dirbaio[m]> it's libraries in the ecosystem that abuse generics and macros to hell
<dirbaio[m]> if you write generic code then instantiate it 100 times of course it's going to build slow
<huayra1[m]> dirbaio[m]: i have an article i should cite for this. please tell me if it's biased or wrong
<dirbaio[m]> it's the same reason c++ has got the reputation for building slow, template hell abuse
<huayra1[m]> dirbaio[m]: "#include <regex>" *waits 5 minutes*
<dirbaio[m]> lmao
<JamesMunns[m]> look at the absolute times
<huayra1[m]> * ``#include `<regex>`` waits 5 minutes
<huayra1[m]> * ``#include <regex>`` waits 5 minutes
<dirbaio[m]> yeah it's particularly bad in c++ because the stdlib itself commits template abuse
<JamesMunns[m]> one or two seconds for a build is not unreasonable, especially when incremental builds are less than a second.