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
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
Amadiro_ has joined #rust-embedded
Amadiro__ has quit [Ping timeout: 240 seconds]
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
rardiol has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
rardiol has joined #rust-embedded
rardiol has quit [Ping timeout: 276 seconds]
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #rust-embedded
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
causal has quit [Quit: WeeChat 3.5]
explore has quit [Quit: Connection closed for inactivity]
GenTooMan has quit [Ping timeout: 276 seconds]
GenTooMan has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
rardiol has joined #rust-embedded
rardiol has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
rardiol has joined #rust-embedded
rardiol has quit [Ping timeout: 240 seconds]
<re_irc> <chemicstry> can someone suggest a good alternative to defmt? I'm building an application with bootloader, where I need to patch binary (embed image size, crc, etc) and it does not play well with defmt. I also can't view logs of both bootloader and application at the same time, because they are linked separately. I've been using "log" in the past, but maybe there is something better? It would be nice if it could optimize out all...
<re_irc> ... debug prints when not enabled like "DEFMT_LOG" env variable does
<re_irc> <chemicstry> maybe someone tried "tracing" on embedded? Seems to support "no_std", but I'm a bit scared of its size
<re_irc> <mabez> chemicstry: Btw you can eliminate logs entirely with the log crate too, I believe it's done via features and or environment variables
rardiol has joined #rust-embedded
rardiol has quit [Ping timeout: 244 seconds]
<re_irc> <chemicstry> mabez: Actually if I don't call "log::set_max_level(LevelFilter::Info)" it automatically figures out to optimise out all Info prints, magic
explore has joined #rust-embedded
rardiol has joined #rust-embedded
rardiol has quit [Ping timeout: 276 seconds]
dc740 has joined #rust-embedded
rardiol has joined #rust-embedded
rardiol has quit [Ping timeout: 240 seconds]
<re_irc> <philip.markgraf> I am trying to install probe-rs/vscode on a new machine and could use some help. After installing the basic probe-rs commands and cloning the probe-rs/vscode repo, I issue the command "yarn" in the repo and get the following error, which I do not know how to resolve: "error ../../../package.json: Name contains illegal characters"
rardiol has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
rardiol has quit [Ping timeout: 264 seconds]
rardiol has joined #rust-embedded
rardiol has quit [Read error: Connection reset by peer]
rardiol has joined #rust-embedded
<re_irc> <jannic> Any idea why an inline-assembly register spec with "in("r8")" fails on nightly, but works on stable and beta?
<re_irc> Nightly says "cannot use register "r8": high registers (r8+) can only be used as clobbers in Thumb-1 code", but on stable and beta, it compiles and generates working code.
<re_irc> <adamgreig> what target are you building for?
<re_irc> <adamgreig> something similar to this has come up before but i can't find it now...
<re_irc> <dirbaio> regression maybe? it's accepted in thumbv7m
<re_irc> <dirbaio> thumbv6m is thumb-2, not thumb-1
<re_irc> <jannic> thumbv6m-none-eabi
<re_irc> <dirbaio> perhaps bisect and report it? https://github.com/rust-lang/cargo-bisect-rustc
<re_irc> <jannic> Strange: It also fails with a months old nighty: "cargo +nightly-2022-03-01-x86_64-unknown-linux-gnu check"
<re_irc> <adamgreig> what instruction are you assembling?
<re_irc> <jannic> It's reproducible on godbolt: https://godbolt.org/z/b6cnG4nM3
<re_irc> <adamgreig> ah yea
<re_irc> <mabez> Looks like it was this PR: https://github.com/rust-lang/rust/pull/93877
<re_irc> <mabez> It's probably correct, but I don't know enough about thumb1 calling conventions to know how the hardware uses these registers
<re_irc> <mabez> By the way, there is an escape hatch in "asm!" you can call the register directly in the asm template string
<re_irc> <mabez> and it'll be passed straight to LLVM
<re_irc> <dirbaio> thumbv6m is thumb-2, not thumb-1
<re_irc> the bug is it thinks it's thumb1 I think...?/
<re_irc> <dirbaio> * think...?
<re_irc> <jannic> mabez: That's also part of current stable and beta so it doesn't explain the differing behavior.
<re_irc> <adamgreig> works fine on thumbv7 on godbolt though, despite neither having the +thumb2 feature set in the target file
<re_irc> <mabez> adamgreig: Yeah thats quite odd. Not sure how that logic ever worked? Unless the features are added implicitly somewhere else in the compiler?
<re_irc> <adamgreig> thumb_mode is added if instruction set is T32, but i don't see thumb2 being added
<re_irc> <adamgreig> anyway it might not be wrong as such
<re_irc> <dirbaio> I think they come from LLVM?
<re_irc> <adamgreig> on ARMv6-M, the MOV immediate instruction can only encode for r0-r7, it only has a T1 encoding
<re_irc> <adamgreig> ARMv7-M includes T2 and T3 encodings that are 32-bit instructions and support high registers (and bigger immediates)
<re_irc> <adamgreig> hmm
<re_irc> <adamgreig> but on stable, it emits "movs r0, #1; mov r8 r0"
<re_irc> <adamgreig> which is fine for v6
<re_irc> <adamgreig> might be an llvm issue?
<re_irc> <9names (@9names:matrix.org)> philip.markgraf: Is this for a rust project? Normally you would use cargo for that, not yarn...
<re_irc> <adamgreig> or if not llvm, it might be that the way it generates the mov code when given a register spec has changed and now invokes the thumb2 check that it didn't before?
<re_irc> <dirbaio> got "cargo bisect-rustc" going ..
<re_irc> <adamgreig> I think this is probably worth filing as a regression bug but yea, be interesting to see where it came
<re_irc> <adamgreig> is there a new llvm recently? if so that's my bet
<re_irc> <dirbaio> nightly-2021-12-09 works, nightly-2021-12-10 fails
<re_irc> <adamgreig> so old
<re_irc> <dirbaio> > ERROR: no CI builds available between e6b883c74f49f32cb5d1cbad3457f2b8805a4a38 and 0b42deaccc2cbe17a68067aa5fdb76104369e1fd within last 167 days
<re_irc> :'(
<re_irc> <adamgreig> github is not a great UI for jumping to a date in the commit history lol
<re_irc> <jannic> That range includes:
<re_irc> commit 908f300dd7878f6bcd0f5479c2db680067aec3d8
<re_irc> Date: Thu Nov 11 12:42:38 2021 +0000
<re_irc> Author: Amanieu d'Antras <amanieu@gmail.com>
<re_irc> <jannic> But then, why does it work on stable/beta?
<re_irc> <adamgreig> but that commit is in stable, yea
<re_irc> <dirbaio> maybe stable/beta are built with different flags or something?
<re_irc> <dirbaio> yeah it's so odd
<re_irc> <jannic> Stable seems to behave completely sensible: It doesn't allocate r8-r15 automatically, but allows to specify it manually. Which IMHO is the most useful way to handle this. One doesn't want to get a high register randomly assigned, as it can only be used with a small subset of instructions. But it can be useful to be able to specify them manually in case one needs a few more in/out registers.
causal has joined #rust-embedded
<re_irc> <yruama_lairba> hi, what is the name of the issue when an interrput occur and modify a register when an other part of software do read,modify,write operation on it ?
<re_irc> <jannic> adamgreig: Filed https://github.com/rust-lang/rust/issues/99071