08:05 <MathiasKoch[m]> double allocation

10:05 <thejpster[m]> a random idea popped into my head - instead of using the PAC to create singletons, each peripheral gets a macro that generates a specially named (non-mangled) static variable. Now the singleton nature of the peripheral is guarded by the linker and name collisions. If you want to share the peripheral, put it in a place where both the main thread function and the ISR function can see it.

10:09 <thejpster[m]> dirbaio: are you using LTO? If so, codegen is performed by your linker. So maybe check which linker you are using, and that they are bit-for-bit the same? Maybe transfer all the object code from one machine to the other and try using the other machine's linker? Or even check if the object code is the same across the two machines?

10:23 <ben[m]> <hadez[m]> "I'm working with a ch32v203k8tx..." <- you should checkout `embedded-hal-bus`

11:23 <thejpster[m]> dirbaio: other ideas - does your tree compile any C code with `cc`? Is your C compiler the same?

11:25 <dirbaio[m]> <thejpster[m]> "dirbaio: are you using LTO? If..." <- it's rust-lld, installed by rustup, and it's identical yep. it also reproduces without LTO though

11:26 <dirbaio[m]> thejpster[m]: no C code, just Rust. (it does link precompiled .a libs from Nordic, but it also reproduces with the embassy examples which are pure rust so it's not that...)

11:26 <dirbaio[m]> it seems it really is just rust itself

11:27 <dirbaio[m]> asm code in the object files is different before linking, so it's not the linker

11:27 <thejpster[m]> but it's the same rustc binary?

11:27 <thejpster[m]> so rustc is pulling something from the environment, or it's one of the libraries it's linked to

11:28 <thejpster[m]> you sure you don't have RUSTFLAGS="-Copt-level=3" ? ;)

11:28 <dirbaio[m]> I also tried "transplanting" all env vars from arch to ubuntu, no change :D

11:28 <thejpster[m]> you could replace rustc with a shell script that logs all environment and arguments to disk and then runs the real rustc

11:28 <thejpster[m]> but we're getting desperate

11:28 <dirbaio[m]> 100% sure no rustflags. they would show up in rustc invocations in cargo -v...

11:29 <thejpster[m]> I don't think they would

11:29 <thejpster[m]> I think rustc reads them and not cargo?

11:29 <dirbaio[m]> hmmmmm

11:29 <dirbaio[m]> I think it's just a Cargo thing?

11:29 <dirbaio[m]> rustc just reads argv

11:30 <dirbaio[m]> at least all the docs I can find on RUSTFLAGS are Cargo, not rustc

11:30 <dirbaio[m]> the annoying thing is Cargo puts different fingerprints on the artifacts

11:31 <dirbaio[m]> so you can't simply hash them and compare

11:31 <thejpster[m]> yeah, maybe you're right

11:31 <thejpster[m]> what's the input to the fingerprint? weird that they aren't the same

11:31 <dirbaio[m]> yeah actually that's a very good question

11:32 <dirbaio[m]> i'm not sure exactly, it's a hash of everything that could cause changes to a crate

11:32 <thejpster[m]> I guess you want "reproduceable builds with rust" or something

11:32 <dirbaio[m]> version, deps, rustflags, rust version

11:32 <thejpster[m]> uid 0, path is /rustc, etc.

11:33 <dirbaio[m]> yeah i've tried googling, but everything I find always starts with "ensure you have same version of compiler, os, etc" 🫠

11:34 <dirbaio[m]> I can already get reproducible builds if I use locally the same docker image CI uses

11:34 <dirbaio[m]> I was just hoping that's avoidable

11:34 <dirbaio[m]> I don't want bit-by-bit reproducible builds, I just want CI not to output a binary that's 10kb bigger than local :D

11:35 <Koen[m]> Unreproducible builds as a service 😁

11:38 <thejpster[m]> well, yeah, if the whole OS is part of making it repeatable than that begs the question ... why?

11:38 <thejpster[m]> can it really be libz?

11:39 <dirbaio[m]> exactly my question 😭

12:06 <JamesMunns[m]> oh wait

12:07 <JamesMunns[m]> change the paths dirbaio

12:07 <JamesMunns[m]> try putting them all at some base /demo path

12:07 <dirbaio[m]> docker on arch vs ubuntu, both with the repo mounted at /code, they still gave different results 🫠

12:07 <JamesMunns[m]> damn

12:17 <dirbaio[m]> lol so the path where rustc is installed changes the results

12:17 <JamesMunns[m]> lolol

12:18 <dirbaio[m]> arch was /home/dirbaio/.rustup, ubuntu was /home/ubuntu/.rustup

12:18 <dirbaio[m]> changing ubuntu to /home/dirbaio

12:18 <dirbaio[m]> now ubuntu is 100 bytes bigger than arch, instead of 10k bigger

12:18 <dirbaio[m]> STILL different

12:18 <JamesMunns[m]> I wonder if the bin path (and other weird metadata) acts as a hash/prng seed

12:19 <dirbaio[m]> yea

12:19 <dirbaio[m]> target/.rustc_info.json seems to imply hte path gets hashed

12:19 <dirbaio[m]> that's how I found it

12:19 <JamesMunns[m]> I know sometimes longer paths end up inhibiting opts sometimes just due to debuginfo size or other similiar shenanigans that make you run out of "optimizer fuel"

12:19 <dirbaio[m]> * target/.rustc_info.json seems to imply the rustc path gets hashed

12:20 <dirbaio[m]> the results don't change if I change the path where the repo is though

12:20 <JamesMunns[m]> I know there was a reproducible builds project for rust at some point, that I think was able to do them in some controlled case?

12:20 <JamesMunns[m]> might be worth hunting for that tracking issue, they've probably at least documented a bunch of things that can impact it

12:22 <JamesMunns[m]> https://github.com/rust-lang/rust/issues/34902 was an old one

12:22 <JamesMunns[m]> some comments say it has regressed since then tho

12:23 <JamesMunns[m]> https://github.com/rust-lang/rust/issues/75362 some notes about paths to libs being important

12:23 <M9names[m]> looks like this one is the current tracking issue: https://github.com/rust-lang/rust/issues/129080

12:24 <dirbaio[m]> making the rustup path the same makes the fingerprints of some crates match, but not all

12:36 <thejpster[m]> interesting

12:36 <dirbaio[m]> ah only MY crates have a different fingerprint ...

12:36 <dirbaio[m]> and the fingerprint json has a "path" key that's different

12:36 <dirbaio[m]> makes sense

12:38 <dirbaio[m]> trying making BOTH the rustc and repo paths the same...

12:38 <dirbaio[m]> takes a while because every time I create a new container it has to clone the insanely bloated CMSIS_5 repo 💩

12:43 <dirbaio[m]> yayyyyy. using the exact same path for rustc AND the repo yields the exact same binary

12:43 <dirbaio[m]> * same binary across arch and ubuntu

12:47 <dirbaio[m]> now how to fix it

12:47 <dirbaio[m]> my theory of what's happening is

12:47 <dirbaio[m]> - different paths trigger different Cargo fingerprints

12:47 <dirbaio[m]> - different crate names cause rustc to emit different code ..??? maybe because order of stuff changes in hashmaps

12:47 <dirbaio[m]> - different fingerprints causes different crate names that rustc sees

12:53 <thejpster[m]> But .. 10K of changes?

12:53 <dirbaio[m]> yeah that worries me as well

12:53 <dirbaio[m]> 10k on a 380k firmware

12:53 <dirbaio[m]> * 380k firmware seems a lot

12:57 <JamesMunns[m]> (2.6%, for anyone else wondering)

12:58 <dirbaio[m]> considering i'm sending PRs to defmt to save 1k it's quite demotivating to lose 10k by the compiler rolling the dice wrong

13:15 <dirbaio[m]> --remap-path-prefix doesn't work 😭

13:15 <dirbaio[m]> it's a rustc thing, cargo still hashes the path

13:15 <dirbaio[m]> * the path into the fingerprints

13:32 <thejpster[m]> Jorge notes that crate paths end up in panic strings. But I doubt that accounts for much here.

13:39 <dirbaio[m]> I already made sure to not have panic strings with panic_immediate_abort 😎

13:39 <dirbaio[m]> I can't afford them! 😭

13:39 <dirbaio[m]> it's the cargo fingerprints

13:39 <dirbaio[m]> definitely the cargo fingerprints

13:39 <dirbaio[m]> that cause butterfly effect random changes all over the place

13:39 <dirbaio[m]> so somehow I have to get Cargo to not hash the paths into them

16:40 <thejpster[m]> this is all very troubling

16:40 <thejpster[m]> I'm thinking "maybe there's 2% to be gained in terms of code space if I just try a few random usernames"