<ryan-summers[m]>
I do not believe so because a generic could possibly implement both sets of traits
<ryan-summers[m]>
I don't think its possible with rust to specify two mutually exclusive sets of traits that a type could implement
<ryan-summers[m]>
* could implement. I think the only exception is the !Sized syntax and others that use the ! specifier\
jedugsem[m] has quit [Quit: Idle timeout reached: 172800s]
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<Ralph[m]>
should we expect the embedded rust ecosystem to adopt core::error::Error (very) fast and just expect it to implement the trait so that we can implement cause or is it not worth the trouble and we re-visit it in a year or two (with embedded-hal v2.0 which would then enforce the trait bound)? (kind of coming back to my question from last week 😅🙈)
<Ralph[m]>
and if everyone is supposed to do it then it can just as well be enforced by embedded-hal (as it'll anyway have the ripple effect)
<diondokter[m]>
Ralph[m]: > <@rursprung:matrix.org> should this be a general recommendation that people start implementing it now and start requiring it where they have generics for other errors? this would mean that crates which do this can only be used with HALs (& other crates) which also implement `core::error::Error... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RhNYFumyRSwgCoItdgiNWmaq>)
<diondokter[m]>
I'm not sure if even that is required
<diondokter[m]>
But yeah, for source which is similar it would be hard to return a good value when the sub error doesn't implement the trait.
<diondokter[m]>
You could write your own wrapper around the non-error error
<Ralph[m]>
sorry, i meant source and not cause 🙈
starblue has joined #rust-embedded
MariusKriegerows has quit [Quit: Idle timeout reached: 172800s]
RobertJrdens[m] has joined #rust-embedded
<RobertJrdens[m]>
There's a lot of benefit in HAL impls offering Error. Let's hope https://github.com/dtolnay/thiserror/pull/304 lands which should make this a lot more convenient.
<Ralph[m]>
i just remembered that most HALs - at least for GPIO pins - anyway use Infallible. and i just checked, this implements Error, so it should be fine 🙂
<jonored>
danielb[m]: I'm guessing that's you taking https://github.com/esp-rs/esp-hal/issues/1662 ? If so let me know if there's anything from me that'd help, and thanks for looking at it. I don't have strong opinions about API apart from that it should be possible in a supported way to get the matrix into all of it's plausibly-useful states _somehow_.
sugoi has joined #rust-embedded
<danielb[m]>
<jonored> "bugadani: I'm guessing that's..." <- Yup, although I'm still not sure how things will look
<thejpster[m]1>
does anyone know how to debug an issue where `cargo` says there is something wrong with `/tmp/rust<random>/thing.o` but when you look `/tmp/rust<random>` has already been deleted?
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
RUSTFLAGS=-Csave-temps
<thejpster[m]1>
I still get /home/jonathan/Downloads/gaisler/sparc-bcc-2.3.0-llvm/bin/sparc-gaisler-elf-ld: unknown architecture of input file /tmp/rustc4jBo9z/symbols.o' is incompatible with sparc output`
<thejpster[m]1>
* I still get /home/jonathan/Downloads/gaisler/sparc-bcc-2.3.0-llvm/bin/sparc-gaisler-elf-ld: unknown architecture of input file \/tmp/rustc4jBo9z/symbols.o' is incompatible with sparc output`
<thejpster[m]1>
s///`//, s///"//, s/'/"/
<thejpster[m]1>
that's the only file in the link that's not in ./target, and it was given in the command that cargo ran to call the linker
<thejpster[m]1>
specifically, it was the first object given the linker.
<dirbaio[m]>
I think with save-temps the file /tmp/rustc4jBo9z/symbols.o should stay there so you can look at it
<thejpster[m]1>
oh, no wait, there's my file. I'm a wally.
<thejpster[m]1>
`/tmp/rustc4jBo9z/symbols.o: ELF 32-bit MSB relocatable, SPARC32PLUS, total store ordering, version 1 (SYSV), not stripped`
<thejpster[m]1>
while the other files are
<thejpster[m]1>
`ELF 32-bit MSB relocatable, SPARC, version 1 (SYSV), with debug_info, not stripped`
<dirbaio[m]>
fun
<dirbaio[m]>
that .o file is synthesized by rustc
<dirbaio[m]>
it's a dummy object whose only job is to force the linker to pull in certain symbols to avoid link failures due to link order (i'm not sure exactly what, I think it's extern symbols or #[used] symbols)
<dirbaio[m]>
seems it's synthesizing it with the wrong arch, probably a bug
AlexandrosLiarok has joined #rust-embedded
<AlexandrosLiarok>
Does anyone know how to force the cc crate to use the cross-compilation linker ? I override the CXX env variable along with TARGET_CXX and RUSTC_TARGET_X_LINKER but the cc command is still available (thank you OSX) and the cc crate seems to fall back to it for linking specifically.
<dirbaio[m]>
the CC variable?
<thejpster[m]1>
when would the cc crate need a linker? It usually makes a staticlib, which is an ar archive full of .o files.
<JamesMunns[m]>
thejpster[m]1: Static libs are still linked together
<thejpster[m]1>
pretty sure they aren't
<thejpster[m]1>
they are just object code in a zip file, but if zip was invented in the 1970s
<dirbaio[m]>
for example for android aarch64 I'm setting CC_aarch64_linux_android and CARGO_TARGET_AARCH64_LINUX_ANDROID_LINKER
<JamesMunns[m]>
thejpster[m]1: Are they just combined with `ar` then?
<thejpster[m]1>
yeah, ar is just zip file but shit
<dirbaio[m]>
(and yes one has to be lowercase and the other uppercase... 😭)
<thejpster[m]1>
now I'm wonder if tar is just the tape version o ar
<thejpster[m]1>
s/o/of/
<thejpster[m]1>
s/wonder/wondering/, s/o/of/
<JamesMunns[m]>
They probably are both just "archive", even if actually unrelated
<JamesMunns[m]>
thejpster[m]1: Hm, I was *somewhat* sure lto is done on static libs, or I'm about to be horrified
<thejpster[m]1>
LTO is done in the linker once it has all the object code (well, bitcode).
jonored[m] has joined #rust-embedded
<jonored[m]>
which, relevantly, is the step that consumes the staticlib, not the step that produces it.
<JamesMunns[m]>
TIL!
K900 has quit [Quit: Idle timeout reached: 172800s]
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
The binary should not include all archives only the parts where stuff is used out of individual .o files of that archive right?
<vollbrecht[m]>
Also if you have a static library A and link it with your rust program `-Wl,--gc-sections` should still have an effect right?
<vollbrecht[m]>
* .o files ( e.g including that .o) of that
<jonored[m]>
the final executable yeah, it'll only include the bits it needs. It's pretty much the same as just passing the link all the .o files separately without having bundled them together.
<thejpster[m]1>
I could imagine there being an esoteric reason why linkers treat a libfoo.a slightly different to just foo1.o foo2.o foo3.o, but yeah, generally they should be equivalent.
<thejpster[m]1>
and rust staticlibs are huge because the pull in most (all?) of the standard library
<thejpster[m]1>
s/ huge/_huge_/, s/the/they/
<dirbaio[m]>
thejpster[m]1: there are indeed esoteric differences :D
<dirbaio[m]>
linking `foo1.o foo2.o foo3.o` will fail if `foo3.o` needs a symbol defined by `foo1.o`
<dirbaio[m]>
while if you link `libfoo.a` the order of the `.o`'s inside it doesn't matter
<thejpster[m]1>
😢
<AlexandrosLiarok>
<dirbaio[m]> "for example for android aarch64..." <- Yea not sure why it doesn't work for me. This is on Macos btw for which cc does some specific checks so maybe it's that?
<AlexandrosLiarok>
Works fine on my nixos system.
<dirbaio[m]>
linkers are cursed man
<jonored[m]>
I was just thinking about the "link order matters and that might yield esoteric differences", but still... mostly equivalent.
<dirbaio[m]>
also I think .a files can contain an "index" of the symbols of the .o files it contains? so that can cause more cursedness :D
<jonored[m]>
and even that is still pretty equivalent in effect to "supplying them all on the command line correctly", which just might involve duplicates and topological sorting that's painful.
<dirbaio[m]>
or the --start-group and --end-group flags 💀
NiaLinaLunaStorm has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]1>
linkers are under-rated. rustc gets all the glory but does no means all of the work.
<thejpster[m]1>
* but does by no means
<vollbrecht[m]>
thejpster[m]1: llvm-lld is still c++ software right? 😅
oluwafemifranch4 has left #rust-embedded [#rust-embedded]
<thejpster[m]1>
yeah took me a while
<thejpster[m]1>
so many buttons
<vollbrecht[m]>
spammer rising, today we had 2 in esp-rs...
<vollbrecht[m]>
and also yesterday one
<thejpster[m]1>
also I'm building rustc right now so firefox is lagging to shit. It's a 10 year old quad core i5-4000 series.
<thejpster[m]1>
I thought we had a bot that pre-emptively banned people
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
spammers seem to have like all the Rust channels in their lists
<i509vcb[m]>
wgpu we get these daily as well
<i509vcb[m]>
even the same accounts lol
<JamesMunns[m]>
thejpster[m]1: Yeah, it does that, doesn't catch all items but if any of the various channel mods ban an account, it gets banned across all rooms in the group.
<roklobsta[m]>
SPARC? In what ancient Sun pizza box?
sugoi has quit [Ping timeout: 252 seconds]
sugoi has joined #rust-embedded
sugoi has quit [Quit: sugoi]
sugoi has joined #rust-embedded
sugoi1 has joined #rust-embedded
sugoi has quit [Ping timeout: 246 seconds]
sugoi1 is now known as sugoi
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Client Quit]
cr1901 has joined #rust-embedded
sugoi has quit [Ping timeout: 246 seconds]
TomB[m] has joined #rust-embedded
<TomB[m]>
Wild is a linker written in rust, seems to be growing in functionality quite fast
sugoi has joined #rust-embedded
NiaLinaLunaStorm has joined #rust-embedded
<NiaLinaLunaStorm>
the stm cube IDE thing has this static analyzer to tell me how much ram the code would use.
<NiaLinaLunaStorm>
Is there something like this for rust?
<NiaLinaLunaStorm>
Also, is there a way to figure out how big the actual uploaded binary is? cause the main file I find in the target dir is WAY bigger than the flash size
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
install cargo-binutils, then you can run cargo size (with --release as appropriate) to see what the size to be flashed is
<NiaLinaLunaStorm>
oki, thanks
<adamgreig[m]>
it will also tell you how much RAM is statically allocated, but not how much might possibly be allocated on the stack during execution
<NiaLinaLunaStorm>
I mean, stuff should be rather static in my case as I am creating objects on startup and then just used those and don't really add any new data (just writes the same values over and over and sends them via USB)