<re_irc>
< (@adamgreig:matrix.org)> it says " The end of the frame record chain is indicated by the address zero in the address for the previous frame."
<re_irc>
< (@adamgreig:matrix.org)> which I think means the FP is what should be 0?
<re_irc>
< (@jamesmunns:beeper.com)> > The end of the frame record chain is indicated by the address zero in the address for the previous frame.
<re_irc>
< (@jamesmunns:beeper.com)> yeah
<re_irc>
< (@jamesmunns:beeper.com)> oh
<re_irc>
< (@jamesmunns:beeper.com)> I might have done fucked up then
<re_irc>
< (@jamesmunns:beeper.com)> that's worth a try
<re_irc>
< (@adamgreig:matrix.org)> and LR is don't-care, uninit on ARMv6M, init to FFFFFFFF on ARMv7M
<re_irc>
< (@adamgreig:matrix.org)> but gdb and probe-run both detect that FFFFFFFF and know to stop unwinding
<re_irc>
< (@jamesmunns:beeper.com)> I (mis)interpreted which one should be zero
<re_irc>
< (@adamgreig:matrix.org)> whereas I don't know if they detect a 0 FP, but let's see
<re_irc>
< (@jamesmunns:beeper.com)> (probe-run will definitely warn)
<re_irc>
< (@adamgreig:matrix.org)> do you think just mov r7, #0 or push { 0, lr }?
<re_irc>
< (@adamgreig:matrix.org)> hmm
<re_irc>
< (@jamesmunns:beeper.com)> can you push immediates like that?
<re_irc>
< (@jamesmunns:beeper.com)> I think the "ideal" is "push nothing, set r7 to zero, let the main prelude stack it"
<re_irc>
(HOST) WARN call stack was corrupted; unwinding could not be completed
<re_irc>
< (@dirbaio:matrix.org)> and "0x2cc" is the "wfe" in the executor
<re_irc>
< (@jamesmunns:beeper.com)> : is that with 467?
<re_irc>
< (@jamesmunns:beeper.com)> you killed the cfi frame for reset, it wont find any info
<re_irc>
< (@dirbaio:matrix.org)> it's not even unwinding out of "Executor::run"
<re_irc>
< (@dirbaio:matrix.org)> the "reset" frame doesn't make a difference
<re_irc>
< (@dirbaio:matrix.org)> it does the same for vanilla cmrt 0.7.2
<re_irc>
< (@jamesmunns:beeper.com)> fair
<re_irc>
< (@dirbaio:matrix.org)> probe-run unwind has never worked reliably for me
<re_irc>
< (@jamesmunns:beeper.com)> I was using Peter's repro case for testing, out of convenience
<re_irc>
< (@jamesmunns:beeper.com)> so not a totally trival test example, it did some defmt stuff
<re_irc>
< (@adamgreig:matrix.org)> i have a tiny demo for my stm32f4 board for this sort of testing, using stm32ral so it recompiles from clean in about 1s lol
<re_irc>
< (@adamgreig:matrix.org)> and no defmt/rtt/formatting to mess up the disassembly
<re_irc>
< (@adamgreig:matrix.org)> the only symbols are main, __pre_init, __delay, HardFault, _0 lol
<re_irc>
< (@dirbaio:matrix.org)> and it's not just async / wfe
<re_irc>
< (@dirbaio:matrix.org)> probe-run is not capable of reaching Reset either here:
<re_irc>
< (@jamesmunns:beeper.com)> I guess stackdump is home-rolled too, but by :D
<re_irc>
- 463 as-is
<re_irc>
< (@jamesmunns:beeper.com)> anyway, it seems like there are two reasonable choices:
<re_irc>
- 463 "With the stack frame pushing removed, but keeping CFI directives"
<re_irc>
< (@adamgreig:matrix.org)> (fwiw "debug=true" is the same as "debug=2" and is generally what you want for embedded)
<re_irc>
< (@jamesmunns:beeper.com)> (the second is == 467 with the top and bottom directives restored, IIRC)
<re_irc>
< (@jamesmunns:beeper.com)> fwiw you have my blessing for either of those, with a weak preference for "as-is, bug probe-run to fix Soon"
<re_irc>
< (@jamesmunns:beeper.com)> not gunna be mad at the second choice tho
<re_irc>
< (@adamgreig:matrix.org)> the cfi directives don't affect the runtime behaviour at least, but not sure what they provide without a corresponding stack frame for reset?
<re_irc>
< (@jamesmunns:beeper.com)> Β―\_(γ)_/Β― they make probe-run not "big mad"
<re_irc>
< (@adamgreig:matrix.org)> hehe
<re_irc>
< (@jamesmunns:beeper.com)> you do need them tho
<re_irc>
< (@jamesmunns:beeper.com)> otherwise that last frame has no debug frame to point to
<re_irc>
< (@jamesmunns:beeper.com)> --- top of stack ---
<re_irc>
< (@adamgreig:matrix.org)> I guess ideally we'd be using a rust naked function which i think will cause the debug info to be emitted
<re_irc>
< (@jamesmunns:beeper.com)> the top and bottom ones say "this is a function I promise"
<re_irc>
< (@dirbaio:matrix.org)> : because probe-run is more mad at "no debug info" than "some debug info, but if I try to use the stack seems corrupted"
<re_irc>
< (@adamgreig:matrix.org)> but sadly the min_naked_fn thing that was considered for the same release as stable asm!() still hasn't made it
<re_irc>
< (@dirbaio:matrix.org)> leaving the cfi directives in makes for a broken call frame
<re_irc>
< (@jamesmunns:beeper.com)> look, you don't have to convince me that probe-run could be more resilient
<re_irc>
< (@jamesmunns:beeper.com)> it should be
<re_irc>
< (@jamesmunns:beeper.com)> : disagree
<re_irc>
< (@jamesmunns:beeper.com)> the callee stacks the frame "for Reset"
<re_irc>
< (@jamesmunns:beeper.com)> so you need the debug info for the callee-stacked frame
<re_irc>
< (@adamgreig:matrix.org)> yea, at least with the cfi directives in, debug info knows about a Reset function at those bounds, so when main stacks the LR pointing back into Reset, the debugger can work out what's going on?
<re_irc>
< (@adamgreig:matrix.org)> maybe? but gdb doesn't seem to care either way
<re_irc>
< (@jamesmunns:beeper.com)> again, not saying probe-run COULD figure that out without the directive
<re_irc>
< (@jamesmunns:beeper.com)> but it CAN'T today, and the directive does nothing to runtime behavior
<re_irc>
< (@dirbaio:matrix.org)> maybe i'm misunderstanding the cfi stuff
<re_irc>
< (@jamesmunns:beeper.com)> the top/bottom ones say "this block of asm is a function called reset"
<re_irc>
< (@dirbaio:matrix.org)> and understanding is not going to come at 2am :S
<re_irc>
< (@jamesmunns:beeper.com)> the middle ones around the old "push" were doing other fuckery
<re_irc>
< (@dirbaio:matrix.org)> i'll add them back
<re_irc>
< (@jamesmunns:beeper.com)> basically "inventing" another stack frame, and telling the debugger about them
<re_irc>
< (@dirbaio:matrix.org)> what about r7? I think the "most correct" is "mov r7, #0" ?
<re_irc>
< (@adamgreig:matrix.org)> I wonder if gdb knows about the cfi functions stuff at all
<re_irc>
< (@adamgreig:matrix.org)> it doesn't seem to do anything different with or without
<re_irc>
< (@adamgreig:matrix.org)> and it considers Reset a "non-debugging symbol" in both cases
<re_irc>
< (@jamesmunns:beeper.com)> I still think it should be "mov r7, sp", but also nothing seems to care.
<re_irc>
< (@adamgreig:matrix.org)> (gdb) bt -past-main on
<re_irc>
#0 lib::inline::__delay (cyc=<optimised out>) at asm/inline.rs:62
<re_irc>
#2 0x0800022a in cortex_m::asm::delay () at /home/adam/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-0.7.7/src/call_asm.rs:19
<re_irc>
#1 lib::__delay (cyc=<optimised out>) at asm/lib.rs:51
<re_irc>
< (@adamgreig:matrix.org)> that's the same with or without the cfi_startproc/cfi_endproc etc
<re_irc>
< (@jamesmunns:beeper.com)> considering right now the callee stacks "whatever happens to be in r7", and everything works okayish, we're probably fine
<re_irc>
< (@jamesmunns:beeper.com)> like, on a clean boot it seems to be zeros in r7, but after a soft reset they certainly aren't cleared
<re_irc>
< (@dirbaio:matrix.org)> r7 is supposed to point at the previous frame (the 2-word struct)
<re_irc>
< (@dirbaio:matrix.org)> there's no frame at "sp"
<re_irc>
< (@jamesmunns:beeper.com)> yes there is
<re_irc>
< (@jamesmunns:beeper.com)> sp == fp because reset uses no stack
<re_irc>
< (@jamesmunns:beeper.com)> oh right
<re_irc>
< (@dirbaio:matrix.org)> there's no 2-word struct at sp
<re_irc>
< (@jamesmunns:beeper.com)> yeah you're right
<re_irc>
< (@jamesmunns:beeper.com)> 2am, I am wrong
<re_irc>
< (@jamesmunns:beeper.com)> make it 0
<re_irc>
< (@adamgreig:matrix.org)> there better not be, because at that point sp is the top of stack so you can't write to it :P
<re_irc>
< (@dirbaio:matrix.org)> ποΈ
<re_irc>
< (@adamgreig:matrix.org)> I think don't set it at all
<re_irc>
< (@adamgreig:matrix.org)> nothing cares and no one else sets it
<re_irc>
< (@jamesmunns:beeper.com)> I prefer deterministic, but I've been wrong a lot today anyway
<re_irc>
< (@dirbaio:matrix.org)> aapcs definitely says to init it to 0
<re_irc>
< (@dirbaio:matrix.org)> otherwise, when main pushes "{r7, lr}", where does that point to?
<re_irc>
< (@dirbaio:matrix.org)> whatever value was in r7 on reset?
<re_irc>
< (@jamesmunns:beeper.com)> yep
<re_irc>
< (@dirbaio:matrix.org)> that could totally throw the unwinder off the rails :P
<re_irc>
< (@jamesmunns:beeper.com)> which is likely 0 on a cold boot, totally random on a not cold boot (and likely another valid fp)
<re_irc>
< (@jamesmunns:beeper.com)> well, "valid" in that it exists in a reasonable stack address
<re_irc>
< (@jamesmunns:beeper.com)> but totally invalid for this boot
<re_irc>
< (@dirbaio:matrix.org)> we've seen bootloaders not initializing VTOR or SP, I wouldn't count on them initializing r7 lol
<re_irc>
< (@jamesmunns:beeper.com)> lmao
<re_irc>
< (@jamesmunns:beeper.com)> what embedded C compiler ships with force frame pointers on?
<re_irc>
< (@adamgreig:matrix.org)> "An UNKNOWN value does not contain valid data, and can vary from moment to moment, instruction to instruction,
<re_irc>
and implementation to implementation. An UNKNOWN value must not be a security hole. UNKNOWN values must not
<re_irc>
be documented or promoted as having a defined value or effect."
<re_irc>
< (@adamgreig:matrix.org)> "UNPREDICTABLE. Means the behavior cannot be relied upon. UNPREDICTABLE behavior must not represent security holes.
<re_irc>
UNPREDICTABLE behavior must not halt or hang the processor, or any parts of the system. UNPREDICTABLE behavior
<re_irc>
must not be documented or promoted as having a defined effect."
<re_irc>
< (@dirbaio:matrix.org)> TIL
<re_irc>
< (@adamgreig:matrix.org)> it is.... pretty similar lol
<re_irc>
< (@dirbaio:matrix.org)> so "implementation-defined"?
<re_irc>
< (@adamgreig:matrix.org)> (from ARM glossary)
<re_irc>
< (@dirbaio:matrix.org)> vs "unpredictable" is "UB"
<re_irc>
< (@adamgreig:matrix.org)> I think behaviour is unpredictable and values are unknown
<re_irc>
< (@dirbaio:matrix.org)> π΅
<re_irc>
< (@dirbaio:matrix.org)> read the register before writing to it, get random behavior?
<re_irc>
< (@dirbaio:matrix.org)> like that ECC RAM that would hardfault if you didn't write to it first π»
<re_irc>
< (@adamgreig:matrix.org)> lol, "UNK/SBZP" is unknown on reads, should be zero or preserved on writes
<re_irc>
< (@adamgreig:matrix.org)> how do you preserve on writes if it's zero on reads...
<re_irc>
< (@adamgreig:matrix.org)> * unknown
<re_irc>
< (@thalesfragoso:matrix.org)> What happens when probe-run sees the stacked r7 as 0 in main ? Does that work ?
<re_irc>
< (@adamgreig:matrix.org)> no, probe-run doesn't have any code to special-case a 0 LR
<re_irc>
< (@adamgreig:matrix.org)> * FP
<re_irc>
< (@adamgreig:matrix.org)> it only looks for the all-1 LR
<re_irc>
< (@adamgreig:matrix.org)> (but, it _could_ learn to stop unwinding when it seems a 0 FP)
<re_irc>
< (@adamgreig:matrix.org)> * sees
<re_irc>
< (@jamesmunns:beeper.com)> probe-run: now aapcs32 compliant unwinding!
<re_irc>
< (@adamgreig:matrix.org)> however, that wouldn't help it with any startup code except cortex-m-rt
<re_irc>
< (@thalesfragoso:matrix.org)> : Isn't that true today already ?
<re_irc>
< (@jamesmunns:beeper.com)> I think it SNAFU on non-rust code anyway tbh
<re_irc>
< (@adamgreig:matrix.org)> one day it might work on risc-v rust code, or someone might want to use it with tock or another runtime, though
<re_irc>
< (@adamgreig:matrix.org)> (it is true that today it requires cmrt's FFFFFFFF LR on the stack)
<re_irc>
< (@thalesfragoso:matrix.org)> : How does it get LR though ?
<re_irc>
< (@adamgreig:matrix.org)> the AAPCS thing is a bit looser than "you must init it to 0", because it offers platforms a lot of flexibility, I think
<re_irc>
< (@dirbaio:matrix.org)> - v2 PR updated
<re_irc>
- opened another PR for initializing r7, since it seems it's orthogonal to the stack align
<re_irc>
< (@jamesmunns:beeper.com)> we're saving so much code size no longer stacking! think of how insignificant this one little "movs r7, #0" is.
<re_irc>
< (@jamesmunns:beeper.com)> second pr could also probably yeet all the "init lr" asm
<re_irc>
< (@adamgreig:matrix.org)> yea, for sure
<re_irc>
< (@jamesmunns:beeper.com)> it's getting clobbered as soon as we "bl" out of "Reset" anyway
<re_irc>
< (@dirbaio:matrix.org)> ohhh
<re_irc>
< (@adamgreig:matrix.org)> it's pointless anyway, more to the point
<re_irc>
< (@jamesmunns:beeper.com)> if we aren't stacking it, we don't need to init it
* re_irc
(@dirbaio:matrix.org) yeets it
<re_irc>
< (@adamgreig:matrix.org)> it's only there because v6 doesn't init it and people wanted it to be all-1s to match v7
<re_irc>
< (@adamgreig:matrix.org)> yea
<re_irc>
< (@adamgreig:matrix.org)> : it gets the LR by unwinding the stack frames; currently c-m-rt pushes the LR of FFFFFFFF onto the stack before branching to main
<re_irc>
< (@adamgreig:matrix.org)> (it uses "bl" to branch, so at that point LR points back into Reset after main)
<re_irc>
< (@adamgreig:matrix.org)> but we're proposing to remove that pushing
<re_irc>
< (@jamesmunns:beeper.com)> oh
<re_irc>
< (@dirbaio:matrix.org)> yeeting done
<re_irc>
< (@thalesfragoso:matrix.org)> : Yeah, but don't you need the FP to unwind ? What happens when it finds a FP of zero ?
<re_irc>
< (@jamesmunns:beeper.com)> pre init could observe the garbo lr
<re_irc>
< (@adamgreig:matrix.org)> pre_init is also "bl" so it will point back to reset
<re_irc>
< (@jamesmunns:beeper.com)> ah, true
<re_irc>
< (@jamesmunns:beeper.com)> I am assuaged.
<re_irc>
< (@adamgreig:matrix.org)> : currently it checks the LR first, sees FFFFFFFF, and stops unwinding
<re_irc>
< (@adamgreig:matrix.org)> I assume it reads the FP from the stack frame but actually I'm not sure it does
<re_irc>
< (@adamgreig:matrix.org)> does it just use the debug info?
<re_irc>
< (@thalesfragoso:matrix.org)> : How can you check LR without the FP to know where it's stacked ?
<re_irc>
< (@adamgreig:matrix.org)> it's looking at the LR and FP in the same stack frame
<re_irc>
< (@adamgreig:matrix.org)> so it's got the previous frame's FP to find both
<re_irc>
< (@adamgreig:matrix.org)> _but_, currently it finds that frame successfully even though startup doesn't set r7
<re_irc>
< (@adamgreig:matrix.org)> which suggests to me it is not reading the FP from main's stack frame
<re_irc>
< (@adamgreig:matrix.org)> (and presumably instead using the debug info)
<re_irc>
< (@dirbaio:matrix.org)> yea, it seems to use just LR
<re_irc>
< (@dirbaio:matrix.org)> - lookup symbol at LR
<re_irc>
- use dwarf to recover register values prior to that call (including old LR)
<re_irc>
- repeat
<re_irc>
< (@thalesfragoso:matrix.org)> Oh, so no FP at all
<re_irc>
< (@dirbaio:matrix.org)> I think frame pointers are only really required to unwind past code that has no debug info
<re_irc>
< (@dirbaio:matrix.org)> because if you have no debug info you can't find the old LR
<re_irc>
< (@dirbaio:matrix.org)> but the frame pointer linked list gives you a "shortcut" to skip these frames (?)
<re_irc>
< (@jamesmunns:beeper.com)> yeah, fp basically is just a linked list of lr values
<re_irc>
< (@jamesmunns:beeper.com)> because the lr is the first stacked thing at the top of every frame
<re_irc>
< (@jamesmunns:beeper.com)> and the fp points to the top of the previous frame
<re_irc>
< (@jamesmunns:beeper.com)> surprising probe-run doesn't use it, because I thought we enabled frame pointers always BECAUSE of probe-run?
<re_irc>
< (@jamesmunns:beeper.com)> but I have no more brain for learning today
<re_irc>
< (@jamesmunns:beeper.com)> maybe it had a side effect of also not clobbering lr so much (or at least stacking it)
<re_irc>
< (@adamgreig:matrix.org)> I don't think frame-pointers influences clobbering LR, it would impact clobbering FP
<re_irc>
< (@adamgreig:matrix.org)> you can look at the current FP to find the LR value on the stack
<re_irc>
< (@adamgreig:matrix.org)> so if anything, it makes it even easier to clobber LR?
<re_irc>
< (@thalesfragoso:matrix.org)> : If you have FPs, it doesn't really matter if you clobber LR, I would guess
<re_irc>
< (@jamesmunns:beeper.com)> ^
<re_irc>
< (@adamgreig:matrix.org)> getting late: I was leaning towards "merge 463 (fix stack alignment, don't break probe-run) now, merge 467 (remove reset's stack frame, breaks probe-run) in a month", mainly because of the big error in probe-run, but since we can downgrade that to a warning in probe-run by keeping the CFI directives (which is what 467 does now), my inclination is more to merge 467, and mention in the changelog/advisory...
<re_irc>
... that probe-run users will get a warning on backtrace until probe-run can be updated
<re_irc>
< (@thalesfragoso:matrix.org)> This is an interesting read, it seems there are some complex unwind tables on dwarf that kinda replaces FPs
<re_irc>
< (@adamgreig:matrix.org)> yea, that's what probe-run uses now, and gdb
<re_irc>
< (@adamgreig:matrix.org)> which is why setting r7=0 in startup has no effect on them: they don't use the FP linked list anyway
<re_irc>
< (@jamesmunns:beeper.com)> // LLVM is eager to trash the link register when calling `noreturn` functions, which
<re_irc>
// breaks debugging. Preserve LR by default to prevent that from happening.
<re_irc>
frame_pointer: FramePointer::Always,
<re_irc>
< (@thalesfragoso:matrix.org)> So how does gdb detects the last frame ?
brazuca has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> I mean, I did say "maybe this has the side effect of not trashing LR"
<re_irc>
< (@adamgreig:matrix.org)> it has several techniques: first, it tries to find the "main" function in lots of ways, and stops unwinding there, which is successful for rust on cortex-m-rt
<re_irc>
< (@thalesfragoso:matrix.org)> * detect
<re_irc>
< (@adamgreig:matrix.org)> if you tell it "-past-main on", it will ignore that and keep unwinding, at which point if it sees a stacked LR of FFFFFFFF it will stop (like probe-run) as a platform special-case, and otherwise it will stop when it detects a duplicate frame (which it does successfully after reset if we don't push LR to the stack)
<re_irc>
< (@adamgreig:matrix.org)> in that latter case it emits a one-line notice that it saw a duplicate stack frame (but you only get this if you've disabled stopping-unwinding-on-main)
<re_irc>
< (@adamgreig:matrix.org)> : weird, because that's _definitely_ not the observed behaviour
<re_irc>
< (@thalesfragoso:matrix.org)> : I think by preserve it means stacks
<re_irc>
< (@adamgreig:matrix.org)> ah, yea, in which case yes, that's right
<re_irc>
< (@adamgreig:matrix.org)> it will stack lr and then use it as a scratch register, but keep r7 (FP) pointing to the stack frame, so you can look up r7 to find out what LR was
<re_irc>
< (@dirbaio:matrix.org)> so is it impossible to disable FPs now? I remember a while ago "-C force-frame-pointers=no" reduced binary size by quite a lot, but it seems to have no effect noe
<re_irc>
< (@dirbaio:matrix.org)> * now
<re_irc>
< (@thalesfragoso:matrix.org)> : Can you explain how it detects this duplicate frame ?
<re_irc>
< (@jamesmunns:beeper.com)> trying to look up what "-fno-omit-frame-pointer" (Clang's version of this flag) does
<re_irc>
< (@thalesfragoso:matrix.org)> : Hmm, I think the only change was to make the default yes
<re_irc>
< (@adamgreig:matrix.org)> maybe you need a custom target instead? not sure
<re_irc>
< (@adamgreig:matrix.org)> : not sure
<re_irc>
< (@thalesfragoso:matrix.org)> : Ok, I was trying to think of something obvious, so probe-run could use it too
<re_irc>
< (@adamgreig:matrix.org)> maybe probe-run should use probe-rs to unwind, instead of its own thing
<re_irc>
< (@jamesmunns:beeper.com)> : at least when you enter a "function body" that uses any stack
<re_irc>
< (@adamgreig:matrix.org)> I think it should be "at all times"? so you should always be able to look at r7 to get the frame
<re_irc>
< (@jamesmunns:beeper.com)> maybe, no idea really
Darius has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> otherwise you have to use the debug info to even know where the frame is, at which point you don't really need the frames
<re_irc>
< (@adamgreig:matrix.org)> aapcs has some example choices platforms might make about when it's ok for fp/r7 to be valid or not, in some cases it's ok to use it I guess
<re_irc>
< (@jamesmunns:beeper.com)> frame records are also used for exception unwinding
<re_irc>
< (@adamgreig:matrix.org)> don't know if/where llvm/rust documents which choice they make but I expect it depends on that frame_pointer setting
<re_irc>
< (@jamesmunns:beeper.com)> so you might not have debuginfo
<re_irc>
< (@jamesmunns:beeper.com)> (if you're doing it yourself)
<re_irc>
< (@adamgreig:matrix.org)> I think exception unwinding does also use debuginfo often?
<re_irc>
< (@adamgreig:matrix.org)> haha, probe-rs does actually use FP=0 as a cue to stop unwinding
<re_irc>
< (@thalesfragoso:matrix.org)> : I think so, that boom function from dirbaio does it, and it's just an udf
<re_irc>
< (@adamgreig:matrix.org)> I wonder if probe-run could easily use probe-rs for unwinding, since it's already using it for actually talking to the chip
<re_irc>
< (@jamesmunns:beeper.com)> thats cuz probe-run ignores the actual frame pointer stuff
<re_irc>
< (@jamesmunns:beeper.com)> (I think?)
<re_irc>
< (@adamgreig:matrix.org)> hm?
<re_irc>
< (@jamesmunns:beeper.com)> and the debuginfo was missing in "boom" until dirbaio added it back
<re_irc>
< (@thalesfragoso:matrix.org)> : Hmm, so probably some dwarf stuff, right ?
<re_irc>
< (@thalesfragoso:matrix.org)> I don't know anything about dwarf .-.
<re_irc>
< (@jamesmunns:beeper.com)> : I assume/hope probe-run can somehow get "stack-top" from the debuginfo
<re_irc>
< (@jamesmunns:beeper.com)> : me neither
<re_irc>
< (@thalesfragoso:matrix.org)> : If it doesn't use FPs, I guess it has to
<re_irc>
< (@adamgreig:matrix.org)> yep cool, I have probe-rs's unwinder/debugger working now, let's see how it handles all the options
<re_irc>
< (@adamgreig:matrix.org)> man, this is much nicer than gdb lol
<re_irc>
< (@jamesmunns:beeper.com)> : low bar
<re_irc>
< (@thalesfragoso:matrix.org)> : if you want to check if force-frame-pointers=no does something, just try compiling that boom example again
<re_irc>
< (@adamgreig:matrix.org)> what we needed at 01:30 is a third column in the matrix :D
<re_irc>
< (@jamesmunns:beeper.com)> > n, no, or off: do not force-enable frame pointers. This does not necessarily mean frame pointers will be removed.
<re_irc>
< (@jamesmunns:beeper.com)> if the target OR the CLI says "always", you get "always always"
<re_irc>
< (@jamesmunns:beeper.com)> and we say "always" for the target
<re_irc>
< (@adamgreig:matrix.org)> so I think probe-run could "just" swap to using probe-rs for unwinding, lose a bunch of tricky code, and get better results
<re_irc>
< (@thalesfragoso:matrix.org)> : That doesn't seem nice. Maybe worth an issue
<re_irc>
< (@adamgreig:matrix.org)> (I don't know how hard "just" is though)
<re_irc>
< (@jamesmunns:beeper.com)> yeah
<re_irc>
< (@jamesmunns:beeper.com)> if anyone wants to drop my links here, it's basically the three parts of the code you want to link to
<re_irc>
< (@jamesmunns:beeper.com)> tl;dr, you need a custom target to disable frame pointers as of today
<re_irc>
< (@jamesmunns:beeper.com)> "frame_pointer_type_attr" basically ORs the target and -C flag settings together.
<re_irc>
< (@adamgreig:matrix.org)> there's a few cortex-m-rt forks that we should probably notify too, come to think of that
<re_irc>
< (@adamgreig:matrix.org)> I think the imxrt people? and rp-rs?
<re_irc>
< (@thalesfragoso:matrix.org)> : I haven't really been following the PRs, sorry. I just fell in this conversation without much context due to the ping
<re_irc>
< (@thalesfragoso:matrix.org)> So not sure if I'm the right one for that, maybe worth waiting for tomorrow ?
<re_irc>
< (@jamesmunns:beeper.com)> "With this PR" vs "With the stack frame pushing removed, but keeping CFI directives". the latter is kinda PR#467 now
<re_irc>
< (@thalesfragoso:matrix.org)> I have been out of the loop for quite some time now, just trying to chime in once in a while for the weird takes.
<re_irc>
But I'm planning in organizing my stuff better to become more active
<re_irc>
< (@thalesfragoso:matrix.org)> * on
<re_irc>
< (@jamesmunns:beeper.com)> I really gotta go tho, no stress to solo run the release tonight if you can't get an r+
<re_irc>
< (@jamesmunns:beeper.com)> we should start circulating that draft tho, to make people aware, and for people to revert to 0.7.0 as a hotfix if they are like, shipping prod binaries today.
<re_irc>
< (@thalesfragoso:matrix.org)> 467 seems fine, I don't know what the cfi does though, do we want to remove it ?
<re_irc>
< (@jamesmunns:beeper.com)> yes
<re_irc>
< (@thalesfragoso:matrix.org)> I would also vote to initialize r7
<re_irc>
< (@jamesmunns:beeper.com)> (the local cfi is basically "debuginfo fixup" for the fake stack frame)
<re_irc>
< (@adamgreig:matrix.org)> (we don't need to remove the cfi_startproc/cfi_endproc)
<re_irc>
< (@jamesmunns:beeper.com)> I wouldn't wait for 468 to release.
<re_irc>
< (@adamgreig:matrix.org)> I don't plan to
<re_irc>
< (@thalesfragoso:matrix.org)> Is there any downside to it ?
<re_irc>
< (@jamesmunns:beeper.com)> 2 extra bytes of ".text"
<re_irc>
< (@adamgreig:matrix.org)> and an extra instruction executed at startup, it's not a huge downside
<re_irc>
< (@adamgreig:matrix.org)> but afaict there's literally zero upside
<re_irc>
< (@thalesfragoso:matrix.org)> : Heh, rustc is summing up a lot more with all the FPs
<re_irc>
< (@thalesfragoso:matrix.org)> : I thought FPs were used a lot more, people seemed to like them
<re_irc>
< (@jamesmunns:beeper.com)> for context
<re_irc>
< (@jamesmunns:beeper.com)> the r7 push JUST initializes the "tail" frame pointer
<re_irc>
< (@jamesmunns:beeper.com)> but all the debuggers _seem_ to do "just fine" even when it is bogus.
<re_irc>
< (@jamesmunns:beeper.com)> we don't know exactly why, AFAIK. AAPCS32 says it should be zero
<re_irc>
< (@jamesmunns:beeper.com)> but like no one else sets it (even though they should?)
<re_irc>
< (@thalesfragoso:matrix.org)> : Maybe it depends on how bogus it's, but I'm not even sure if they really use it, so I got nothing
<re_irc>
< (@peter9477:matrix.org)> I see two sort-of benefits: 1) if someone is going to be the first one to do this, why not "us", and 2) if it's a documented standard, it feels kind of inline with the Rust ethos to strictly adhere to it. That said, my slight bias here is in line with my pedantic nature, and it's totally the sort of thing I'd do just to feel that everything was "clean". I don't like random contents in RAM, and...
<re_irc>
... letting a randomized register survive past the runtime startup code feels wrong too.
<re_irc>
< (@jamesmunns:beeper.com)> I generally agree, but I am also generally fine kicking this to a "post 0.7.3 discussion"
<re_irc>
< (@thalesfragoso:matrix.org)> : Right, we have miscompilations, makes sense
<re_irc>
< (@peter9477:matrix.org)> I agree with that too... certainly hard to argue that one is in any way urgent.
<re_irc>
< (@thalesfragoso:matrix.org)> : I can r+ a release if you want
<re_irc>
< (@peter9477:matrix.org)> Very minor wording mistake: "are you" should be "you are" in "so if you have a potentially affected configuration are you strongly advised to upgrade to 0.7.3."
<re_irc>
< (@jamesmunns:beeper.com)> I appreciate the delicate tempering of wording wrt affected configurations :)
<re_irc>
< (@peter9477:matrix.org)> : forgot to tag you there
<re_irc>
< (@adamgreig:matrix.org)> thanks! fixed
<re_irc>
< (@adamgreig:matrix.org)> , if you're around...
<re_irc>
< (@jamesmunns:beeper.com)> thank you for pushing this through, and countering my recklessly and freshly gained opinions :). I know it's late for you too.
<re_irc>
< (@adamgreig:matrix.org)> : the reason "why not us" is that even if debuggers did start doing this, it still doesn't gain anyone anything, because the debuggers already terminate unwinding OK
<re_irc>
< (@adamgreig:matrix.org)> in a different, better, world, everyone would have done it and debuggers would use it and we'd all scowl at the one startup that didn't do it and make them change it (or add workarounds to all the debuggers)
<re_irc>
< (@adamgreig:matrix.org)> but it's not clear to me there's a path from this world to that world
<re_irc>
< (@adamgreig:matrix.org)> (however I would really like to see if any other startup code did do this)
<re_irc>
< (@jamesmunns:beeper.com)> A discussion for an earlier hour, another day :)
<re_irc>
< (@adamgreig:matrix.org)> and I appreciate the argument that we could do better for the sake of doing better, and maybe others will follow...
<re_irc>
< (@adamgreig:matrix.org)> but yea, it's not getting in for 0.7.3 either way :P
<re_irc>
< (@jamesmunns:beeper.com)> (fwiw I skimmed zephyr's startup code, didn't see them init r7, but also a little unclear on their "asm to c" transition
<re_irc>
< (@adamgreig:matrix.org)> I'm still amazed libopencm's startup is in C tbh
<re_irc>
< (@adamgreig:matrix.org)> wonder what that does to the initial stack frame!
<re_irc>
< (@adamgreig:matrix.org)> probably pushes the cpu UNKNOWN value for r7 to the stack immediately lol
<re_irc>
< (@jamesmunns:beeper.com)> as far as I can tell: yes.
<re_irc>
< (@jamesmunns:beeper.com)> (if the C code is compiled with the standard prelude)
<re_irc>
< (@newam:matrix.org)> You might get asked to review that for licensing since rustsec advisories are in the public domain
<re_irc>
< (@peter9477:matrix.org)> : Not that there was any real question about it after that thorough investigation, but I can confirm that on nightly 2023-02-09 and with cortex-m-rt 0.7.3 our real firmware works again without the problems that led to identifying this issue. (For those who weren't there at the start, it was when we updated to nightly 2023-02-05 or later, with cortex-m-rt 0.7.2.) Thanks for the many hours you all put...
<re_irc>
... into this, and I'm sure I speak for many others, especially those who will now continue not realizing there was ever a latent problem in their system. ;)
lehmrob has joined #rust-embedded
<re_irc>
< (@jannic:matrix.org)> Lol, me: let me _quickly_ read what they decided about that bug, while drinking my morning coffee.... 1h later: still reading :-)
<re_irc>
< (@diondokter:matrix.org)> Thanks for the work!
<re_irc>
Just FYI, `stackdump`'s unwinding works the same as (at least an older version of) probe-run. Guess where I got the inspiration from haha
<re_irc>
I've made an issue too to check out if it breaks.
<re_irc>
Unwinding isn't always reliable, bit honestly, stackdump and probe-run are often not any worse than GDB. I think a whole lot could be improved by the compiler to generate better DWARF info
fabic_ has quit [Ping timeout: 252 seconds]
<re_irc>
< (@therealprof:matrix.org)> : I didn't play along, sorrt.
<re_irc>
< (@therealprof:matrix.org)> * sorry.
fabic_ has joined #rust-embedded
dnm has quit [Ping timeout: 255 seconds]
nohit has quit [Ping timeout: 255 seconds]
nohit has joined #rust-embedded
dnm has joined #rust-embedded
<re_irc>
< (@boiethios:matrix.org)> I almost finished my keyboard firmware, then I ran into a project where the layout is written as a file, which the firmware uses to generate the layout dynamically. That allows them to change the layout on-the-fly, key by key. I wouldn't have thought it's possible. How can they modify a file in the flash memory like that?
<re_irc>
< (@boiethios:matrix.org)> Can I do that in my Rust code?
<re_irc>
< (@k900:0upti.me)> Maybe it's just parsed at build time?
<re_irc>
< (@k900:0upti.me)> But you could also store configuration in flash memory if you wanted
<re_irc>
< (@boiethios:matrix.org)> : I don't think that's what they do. They change the config without reflashing the firmware: https://get.vial.today/
<re_irc>
< (@k900:0upti.me)> Vial (and VIA, and most other QMK derivatives) have a custom USB protocol that allows them to send config to the firmware in some predefined format
<re_irc>
< (@k900:0upti.me)> And then the firmware can keep it in memory or dump it to flash, if one is available
<re_irc>
< (@boiethios:matrix.org)> : That doesn't look trivial. I think I'll stick with what I do right now.
<re_irc>
< (@boiethios:matrix.org)> : Do you mean they write in the same flash the firmware is?
<re_irc>
< (@k900:0upti.me)> It depends on the exact hardware
<re_irc>
< (@boiethios:matrix.org)> There must be another one dedicated to that, right?
<re_irc>
< (@k900:0upti.me)> Some devices have separate flash chips for configuration
<re_irc>
< (@k900:0upti.me)> Some use onboard flash on the SoC
<re_irc>
< (@boiethios:matrix.org)> : That looks so unsafe from a Rust pov
<re_irc>
< (@k900:0upti.me)> Why?
<re_irc>
< (@boiethios:matrix.org)> Unless I misunderstand you.
<re_irc>
< (@boiethios:matrix.org)> They modify only a part of the firmware, that's what you say? The part where the config is
<re_irc>
< (@k900:0upti.me)> They don't modify the _code_ of the firmware
<re_irc>
< (@k900:0upti.me)> Generally
<re_irc>
< (@k900:0upti.me)> They just store configuration in a different place on the same physical flash
<re_irc>
< (@boiethios:matrix.org)> So, what they do is they keep a static somewhere that acts as a file, and they modify that part whenever needed?
<re_irc>
< (@k900:0upti.me)> Basically
<re_irc>
< (@k900:0upti.me)> It's not really a _static_
<re_irc>
< (@k900:0upti.me)> As in it's not a Rust "static"
<re_irc>
< (@k900:0upti.me)> It's just a location in the flash memory
<re_irc>
< (@boiethios:matrix.org)> Can I do that with the stm32 crate?
<re_irc>
< (@k900:0upti.me)> Yes
<re_irc>
< (@jannic:matrix.org)> You still need to be careful, for example it should not look like reading an uninitialized value, otherwise the rust compiler could apply strange "optimizations" (undefined behavior). I'm not sure about the exact rules though.
<re_irc>
< (@k900:0upti.me)> Reading from flash should never be uninit
<re_irc>
< (@k900:0upti.me)> Since it's not Rust owned memory
<re_irc>
< (@k900:0upti.me)> But you will have to care about things like wear leveling and such
<re_irc>
< (@boiethios:matrix.org)> : I haven't thought about that.
<re_irc>
< (@boiethios:matrix.org)> But I'm not sure which oom is the number of writes I have
<re_irc>
< (@jamesmunns:beeper.com)> 10000 erases, usually
<re_irc>
< (@k900:0upti.me)> Generally it's less about "how many writes you have" and more about "how evenly can you spread the writes"
<re_irc>
< (@jamesmunns:beeper.com)> I mean, yes, but the flash will be rated for 10k erases (or so) per block/page.
<re_irc>
< (@jamesmunns:beeper.com)> leveling is about not running into that limit as quickly
<re_irc>
< (@jamesmunns:beeper.com)> so: don't write logs to it every minute, but if you flash key configs once a week you'll be good for a couple hundred years.
<re_irc>
< (@boiethios:matrix.org)> I plan to build a new keyboard, maybe it's worth it to add a card reader and put the configuration on a SD card. I could also write logs, etc to it
<re_irc>
< (@diondokter:matrix.org)> If you do want to have regular value writes, I have made a crate a while ago that does that as efficiently as possible: https://crates.io/crates/sequential-storage
<re_irc>
< (@boiethios:matrix.org)> I assume a full YAML (or equivalent) parser cannot fit on a SoC, right? I need to store the config in some kind of binary format that I can decode directly.
<re_irc>
< (@k900:0upti.me)> It can
<re_irc>
< (@k900:0upti.me)> But it will be slow
<re_irc>
< (@k900:0upti.me)> And like, why
<re_irc>
< (@k900:0upti.me)> It'll be easier to use some less expensive format
<re_irc>
< (@boiethios:matrix.org)> : Are you thinking about a human readable less expensive format? Which one?
<re_irc>
< (@k900:0upti.me)> It doesn't need to be human readable
<re_irc>
< (@jamesmunns:beeper.com)> (bias: I wrote postcard)
<re_irc>
< (@k900:0upti.me)> You can just have a small tool that converts a human readable config to a machine readable one
<re_irc>
< (@k900:0upti.me)> Because you're going to need a tool anyway to upload it
<re_irc>
< (@diondokter:matrix.org)> : Postcard is great nonetheless :D
<re_irc>
< (@jamesmunns:beeper.com)> postcard uses serde, so agreed with k900. you could have json or toml on the desktop, deserialize it, then serialize to postcard for the mcu.
<re_irc>
< (@k900:0upti.me)> (unless you just copy the VIA/Vial protocol, I guess, in which case you'll also be copying literally all of QMK semantics, in which case maybe just use QMK)
<re_irc>
< (@boiethios:matrix.org)> : The issue is that their configuration options are quite limited, and I do NOT want to dive in the QMK code. That's why I wrote my firmware in Rust in the first place.
<re_irc>
< (@marmrt:matrix.org)> If your config is not that complex you might wanna look at serde and JSON
<re_irc>
< (@k900:0upti.me)> : Well, you're going to need your own data model then
<re_irc>
< (@boiethios:matrix.org)> : I bet having ones own USB protocol is the hardest problem here, not the data model.
<re_irc>
< (@k900:0upti.me)> Not really
<re_irc>
< (@k900:0upti.me)> I believe the way QMK does it is by just shoving all the custom data into a single HID report
<re_irc>
< (@boiethios:matrix.org)> Oh, so that's not a custom protocol, they merely use the HID one.
<re_irc>
< (@k900:0upti.me)> It's a custom protocol wrapped inside a HID report
<re_irc>
< (@boiethios:matrix.org)> Yeah, it's a hack, but a easy one to put in place
<re_irc>
< (@k900:0upti.me)> A lot of USB stuff works like this because it's easy to send arbitrary HID reports from userspace on pretty much all platforms
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
< (@boiethios:matrix.org)> * an
<re_irc>
< (@boiethios:matrix.org)> : I'll keep that in mind, that may prove to be useful
<re_irc>
On March 11th/12th there are Chemnitzer Linuxtage. I'll be running a booth with some colleagues from https://matrix.to/#/#riot-os:matrix.org showing off our embedded OS. It's in C, but there's a lot of Rust that can be done with it, so drop by!
<re_irc>
< (@jannic:matrix.org)> : Depends on what you are doing. It might be tempting to define a static variable with a "#[link_section = "some_flash_range"]" to have easy access to the values stored in flash. But then, the rust compiler might notice that you never write to that location and do strange things.
<re_irc>
And if you access the value by dereferencing a raw pointer, it's not obvious how to apply https://doc.rust-lang.org/std/ptr/index.html#safety: How can "the memory range of the given size starting at the pointer must all be within the bounds of a single allocated object" be satisfied for memory not even managed by rust? The consensus seems to be that it's fine, out of necessity: How to write bare metal software, otherwise? But...
<re_irc>
... it's not documented properly, AFAIK.
<re_irc>
< (@elpiel:matrix.org)> Hello everyone,
<re_irc>
I've been struggling with embassy for a week now because something with the PubSubChannel does not work on my RP PI Pico, it just hangs on both Publisher and receiver and I use both cores (multicore) for the job.
<re_irc>
Here's a very trimmed version of the problematic example:
<re_irc>
< (@jamesmunns:beeper.com)> Just tweeted from the rustembedded account - if anyone can help signal boost it would be much appreciated!
<re_irc>
< (@jamesmunns:beeper.com)> (re: the c-m-rt announcement)
<re_irc>
< (@chrysn:matrix.org)> Happy to boost it if there's something over on mastodon ;-)
<re_irc>
< (@jamesmunns:beeper.com)> If y'all are in any other side matrix rooms that are also rust+cortex-m, please make sure https://github.com/rust-embedded/cortex-m/discussions/469 is shared there too! We want to get everyone updated ASAP.
<re_irc>
< (@jamesmunns:beeper.com)> (this is a "drop what you are doing and update" sort of deal :) )
<re_irc>
< (@jamesmunns:beeper.com)> : I dunno who to ping other than and , but feel free to make a post now and retweet/post/whatever the official one later
<re_irc>
< (@diondokter:matrix.org)> Ah, will something like dependabot pick that up as well?
<re_irc>
< (@jamesmunns:beeper.com)> I thiiiiiink so?
<re_irc>
< (@jamesmunns:beeper.com)> I dunno how the rustsec machinery works.
<re_irc>
< (@adamgreig:matrix.org)> dependabot should just pick up on the normal release anyway aiui
fabic_ has joined #rust-embedded
lehmrob has quit [Ping timeout: 256 seconds]
<re_irc>
< (@jannic:matrix.org)> Does it somehow help to update libraries with dependencies on cortex-m-rt? As I understand it, it does not, unless there is strict dependency on "=0.7.1" or "=0.7.2". A binary with an existing Cargo.lock would not pick up the updated library automatically, and on "cargo update" the dependency on cortex-m-rt would be updated automatically anyway, right?
<re_irc>
< (@dirbaio:matrix.org)> yeah, end-user bin crates have to take action anyway, so there's not much point
brazuca has quit [Quit: Client closed]
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
<re_irc>
< (@pixelhamster:matrix.org)> eh my rust toolchain just broke down or something
<re_irc>
error: the 'cargo' binary, normally provided by the 'cargo' component, is not applicable to the 'nightly-2022-11-29-x86_64-unknown-linux-gnu' toolchain
<re_irc>
< (@jamesmunns:beeper.com)> Also links to the specific aapcs32 section we were violating.
rardiol has quit [Client Quit]
rardiol has joined #rust-embedded
fabic_ has quit [Ping timeout: 255 seconds]
<re_irc>
< (@adamgreig:matrix.org)> Just heading home so will be a few mins late for meeting start but you can probably guess what the first announcement will be π
<re_irc>
< (@adamgreig:matrix.org)> hi room , meeting time! agenda is https://hackmd.io/7HD31UKJQEmzgAO63lEUlg, please add anything you'd like to announce/discuss as usual
<re_irc>
< (@adamgreig:matrix.org)> if you're using probe-run, this will trigger a new warning when it displays a stack trace, but the warning is harmless and hopefully can be fixed in probe-run soon
<re_irc>
< (@adamgreig:matrix.org)> hmm, that's all the announcements I had actually, anyone have anything else?
<re_irc>
< (@jannic:matrix.org)> Many thanks to everybody involved! Reading the backlog took some time, but I was, once again, thrilled by the extraordinarily great collaboration happening in this channel!
<re_irc>
< (@adamgreig:matrix.org)> yep, a huge thanks to everyone involved in this! not least finding out what was going wrong in the first place over in #embassy-rs:matrix.org (https://matrix.to/#/#embassy-rs:matrix.org), imagine working from "huh, this function doesn't seem to be working" to "ah, cortex-m-rt is unaligning the stack on startup"
<re_irc>
< (@adamgreig:matrix.org)> in particular, suggesting redirecting it to the showcase, with maybe a slight update to the showcase page to include more prominent links to github etc
<re_irc>
< (@dkhayes117:matrix.org)> That sounds very interesting
<re_irc>
< (@dkhayes117:matrix.org)> I like it
<re_irc>
< (@eldruin:matrix.org)> any other alternatives are welcome, just something more than a placeholder
<re_irc>
< (@adamgreig:matrix.org)> I like it too. I'd like it even more if we had some more showcase entries maybe π
<re_irc>
< (@eldruin:matrix.org)> : indeed
<re_irc>
< (@dkhayes117:matrix.org)> I haven't started my podcast just yet, but I was thinking of doing an embedded showcase bit from this
<re_irc>
< (@eldruin:matrix.org)> sounds great!
<re_irc>
< (@eldruin:matrix.org)> maybe we can motivate some other people to add stuff there. something like stabilizer or some neotron board?
<cr1901>
Maybe include a blurb of some projects on the page along w/ prominent links to the GH pages?
<cr1901>
I'd love to plug AT2XT more :P
<re_irc>
< (@adamgreig:matrix.org)> so maybe make the header bar a little bigger and add some more welcome/explanatory text, add links?
<re_irc>
< (@eldruin:matrix.org)> yeah sounds good
<re_irc>
< (@eldruin:matrix.org)> maybe some satellite story?
lehmrob has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> do you reckon just set up a redirect rust-embedded.org -> showcase.rust-embedded.org?
<re_irc>
< (@therealprof:matrix.org)> Like the one did in the early days? π
<re_irc>
< (@eldruin:matrix.org)> I'll take anything that looks cool and somewhat nicely done
<re_irc>
< (@eldruin:matrix.org)> wrt. redirect or direct hosting I am not sure
<re_irc>
< (@eldruin:matrix.org)> redirect might be fine as well
<re_irc>
< (@adamgreig:matrix.org)> I think it's probably simpler
<re_irc>
< (@adamgreig:matrix.org)> sounds good then, do you want to have a go at updating the showcase template?
<re_irc>
< (@eldruin:matrix.org)> sure, I was poking at it due to the CI failure
<re_irc>
< (@adamgreig:matrix.org)> ah thanks for looking at that too
<re_irc>
< (@eldruin:matrix.org)> I can make a first draft and then you can take it apart :)
<re_irc>
< (@adamgreig:matrix.org)> ποΈ
<re_irc>
< (@adamgreig:matrix.org)> thanks for suggesting it, good idea!
<re_irc>
< (@adamgreig:matrix.org)> two other cortex-m items from the week, one around asm::delay, which it turns out currently delays for about 1.5x clock cycles on cortex-m0/1/2/3/4 and 0.5x cycles on cortex-m7, and I don't know about the m23/33/etc, so it's a bit annoying for everyone
<re_irc>
< (@adamgreig:matrix.org)> it used to be about 1x on m0/1/2/3/4, which pleased most people, but then m7 was like 0.25x or something, so someone fixed it to be 1x on m7 and "more than 1" on the rest, but that fix wasn't actually right, so it's still only 0.5x on m7
<re_irc>
< (@adamgreig:matrix.org)> and every time we change it everyone's delays will change, too, so
<re_irc>
< (@adamgreig:matrix.org)> it might be that the best thing to do now is document how long it takes on typical cores, and precisely how many instructions of which type it retires, and don't change it so at least it's consistent, but it's still kind of annoying for people to use in that case
<re_irc>
< (@adamgreig:matrix.org)> we could deprecate it and make a new function, but we can't necessarily do any better really - we could go as far as detecting cpu at runtime, but in addition to overhead for small delays, we can't tell how many cycles an instruction will take in advance anyway, because of caches, flash wait states, bus contention, etc etc etc
<re_irc>
< (@adamgreig:matrix.org)> the cm7 especially is all over the place depending on like the alignment of the loop instructions and such
<cr1901>
Hot take- don't use a pipelined/cached CPU core for tight timing like that
<cr1901>
More seriously, I'm for changing the docs
<re_irc>
< (@adamgreig:matrix.org)> it's usually used for like "I just wanna delay a bit, i don't especially care exactly how long, and it's too difficult to get a eh::Delay impl because they can't be shared, so I'll use asm::delay", I think
<cr1901>
eh::Delay consumes a timer internally, correct?
<re_irc>
< (@adamgreig:matrix.org)> though conceivably someone's using it for super tight timing, but they'd probably need to do their own asm around it for that to really make sense
<re_irc>
< (@adamgreig:matrix.org)> well it doesn't have to
<re_irc>
< (@adamgreig:matrix.org)> but that was a whole discussion a week or two back. in most current implementations it does, yea
<cr1901>
I'll have to look at the internals for a cortex-m HAL impl to comment more
<re_irc>
< (@jamesmunns:beeper.com)> Doesn't cortex m (or maybe just cmrt) already have weird cfgs from a build script for things?
<re_irc>
< (@jamesmunns:beeper.com)> This is the worst idea, bit we could guess better on the cycles/nop count?
<re_irc>
< (@jamesmunns:beeper.com)> * but
<re_irc>
< (@adamgreig:matrix.org)> you can't tell m4 from m7 based on target
<re_irc>
< (@jamesmunns:beeper.com)> Drat.
<cr1901>
Have the PACs set a cfg?
<re_irc>
< (@adamgreig:matrix.org)> its build cfgs are for armv6m/armv7m/armv7em/armv8m_main/armv8m_base
<cr1901>
that's part of a cortex_m namespace?
<cr1901>
e.g. #[cfg(cortex_m_nop_cycles = 2)]
<re_irc>
< (@jamesmunns:beeper.com)> Stop providing a delay and just provide the nop function?
<re_irc>
< (@adamgreig:matrix.org)> tbh I'd rather suggest HALs provide an asm::delay
<re_irc>
< (@jamesmunns:beeper.com)> Do we provide a delay impl somewhere?
<re_irc>
< (@adamgreig:matrix.org)> at least they know what chip/cpu it is
<re_irc>
< (@jannic:matrix.org)> Perhaps specify the actual asm loop it executes, and let the caller worry about the actual delay length?
<re_irc>
< (@adamgreig:matrix.org)> : yea, that's what I mean by "and precisely how many instructions of which type it retires"
<re_irc>
< (@adamgreig:matrix.org)> but it's not a very user friendly approach I think
<re_irc>
< (@jamesmunns:beeper.com)> Like, Delay as in the trait
<re_irc>
< (@adamgreig:matrix.org)> yea, cortex_m does, using systick
<cr1901>
What are the downsides to passing cfg options in a build-script provided by the PAC?
<re_irc>
< (@adamgreig:matrix.org)> it has the same problem as most Delays in that it's not shareable
<re_irc>
< (@adamgreig:matrix.org)> (we did discuss making an asm-based delay, and a shared systick based delay, a couple weeks ago, they're still good ideas)
<re_irc>
< (@adamgreig:matrix.org)> cr1901: we don't do it for anything else, but I'm not even sure how it would work (you can't write "#[cfg(bla=2)]" can you?)
<re_irc>
< (@adamgreig:matrix.org)> you can add cfgs with command line flags but can a crate in your dependency tree?
<re_irc>
< (@adamgreig:matrix.org)> hmm, from its build script? do they get included for dependents?
<cr1901>
a crate's build script can
<cr1901>
ohhh, hmmm
<cr1901>
I don't know
<re_irc>
< (@adamgreig:matrix.org)> even so I'm not sure it's a great solution, the PACs don't know this from the SVD
<re_irc>
< (@adamgreig:matrix.org)> and it can vary at runtime depending on the chip configuration and what memory the code is stored in
<re_irc>
< (@adamgreig:matrix.org)> XIP from uncached SPI flash will be very different to running out of ITCM or something
<cr1901>
Ahhhhh, fair point
<cr1901>
I didn't think of that
<cr1901>
And also, in my approach, I would have to think about how to lay out the crates
<re_irc>
< (@adamgreig:matrix.org)> for most cortex-m0/1/2/3/4 that's got a "normal" sort of configuration, we can make an asm loop that does take about 1x cycles to run
<re_irc>
< (@adamgreig:matrix.org)> because we know that subs will be 1 and bne will be 3, so 4 cycles per loop iteration, easy
<cr1901>
I mainly wanted to point out that "yes, you can pass custom cfgs from cargo build scripts to rustc, and some crates on crates.io do so (openssl?)"
<re_irc>
< (@adamgreig:matrix.org)> but changing back to that at this point might not be worthwhile if people have gotten used to the current 1.5x behaviour
<re_irc>
< (@adamgreig:matrix.org)> still... 1.5x is really annoying as a constant factor if you want to block for 1M cycles and have to write like 666_666
<re_irc>
< (@jamesmunns:beeper.com)> Wasn't kidding about "remove delay, just let users write their own nop loop" :p
<re_irc>
< (@jamesmunns:beeper.com)> Let it be its own crate with a million tunable features lol
<re_irc>
< (@adamgreig:matrix.org)> calling asm::nop in a rust for loop will be much much harder to predict timing of
<re_irc>
< (@adamgreig:matrix.org)> it's such a handy thing to exist
<re_irc>
< (@jamesmunns:beeper.com)> : I mean... We're not doing great so far either.
<re_irc>
< (@therealprof:matrix.org)> Provide a configurable proc macro to allow a HAL to do provide a finetuned delay without having to reinvent the wheel?
<re_irc>
< (@adamgreig:matrix.org)> we're a lot better than for _ in 0..n { asm::nop() } would be, though!
lehmrob has quit [Ping timeout: 255 seconds]
<re_irc>
< (@dkhayes117:matrix.org)> Maybe add a "prescaler" with a default value, but could be explicitly changed to adjust the timing?
<re_irc>
< (@adamgreig:matrix.org)> I wonder if you could use a const generic parameter to adjust the asm generation π€
<re_irc>
< (@9names:matrix.org)> Or do what we currently do, which is encourage people to use other delays of they want precision
<re_irc>
< (@therealprof:matrix.org)> Nothing would be worse than saying HALs have to implement it and then having dozens of wrong clones floating around.
<re_irc>
< (@9names:matrix.org)> * if
<cr1901>
>Let it be its own crate with a million tunable features lol <-- I unironically like this idea
<re_irc>
< (@adamgreig:matrix.org)> yea, I guess the question is basically "assuming we keep asm::delay, should we keep the behaviour the same (annoying for everyone but unchanged) but document it better, or revert it so it's 1x on most cores and document that, or try to do some magic"
<re_irc>
< (@jamesmunns:beeper.com)> Is there an instruction that is valid on M0 but aborts the pipeline in M7?
<re_irc>
< (@adamgreig:matrix.org)> if HALs have a "wrong clone" I think it's just a HAL bug they can fix, this is a three-line function body
<re_irc>
< (@therealprof:matrix.org)> : Getting it right is hard, getting it right under all circumstances even more so.
<re_irc>
< (@adamgreig:matrix.org)> there are some instructions the M7 won't dual-issue, or can be configured to not dual-issue, though I don't think this should be changing cpu config registers
<re_irc>
< (@adamgreig:matrix.org)> but I think that's sort of immaterial given the variable delays on M7 anyway
<re_irc>
< (@kevlan:matrix.org)> My vote would be less magic. If someone needs precise timing then use a timer. Though being close-ish to 1x on most platforms would be the preferable.
<re_irc>
< (@adamgreig:matrix.org)> or put another way: I don't think we can do better than guarantee that a particular number of a few types of instruction will be retired, e.g. "N "subs" and N "bne", all but one taken", as a _guarantee_
<cr1901>
If it's not going overboard... could there be a benchmark with a logic analyzer to analyze timing jitter (lower the clock frequency obvs)?
<cr1901>
for various cortex-m cores
<re_irc>
< (@adamgreig:matrix.org)> but we can choose to make that about N clock cycles on CM0-4 platforms, at the cost of changing the current behaviour again
<re_irc>
< (@adamgreig:matrix.org)> and then if stm32h7xx-hal or whatever wanted, it could have its own asm delay that retired more instructions to make it also about 1x, or it could not, the cortex-m one is still available
<re_irc>
< (@adamgreig:matrix.org)> I don't know what that would accomplish exactly
<re_irc>
< (@kevlan:matrix.org)> cr1901: Don't even need the LA, just benchmark it against a timer.
<re_irc>
< (@adamgreig:matrix.org)> and the clock frequency will be important - different flash wait states at higher core clocks
* re_irc
(@chrysn:matrix.org) quietly hums the tune of 386 generation PCs starting up
<re_irc>
< (@therealprof:matrix.org)> Just saying, if the hive mind has troubles getting it somewhat rightish, I wouldn't expect different HAL authors to do a much better job.
<re_irc>
< (@adamgreig:matrix.org)> the HAL authors have the huge advantage of knowing which chip they're running on, which is the main thing that changes the timing
<cr1901>
> I don't know what that would accomplish exactly <-- so ppl know the worst case jitter for their platform's delay
<re_irc>
< (@adamgreig:matrix.org)> so I reckon they'd stand a fighting chance
lehmrob has joined #rust-embedded
<cr1901>
they can then figure out whether delay() is actually appropriate for their use case
<re_irc>
< (@therealprof:matrix.org)> That's why I suggested providing a proc macro with a ton of tweaking options (or a generic function as you suggested).
<re_irc>
< (@adamgreig:matrix.org)> cr1901: the jitter is going to just depend on like, IRQ load, maybe DMA bus contention, that sort of thing, not really predictable or dependent on the chip model
<re_irc>
< (@adamgreig:matrix.org)> the scaling factor is stable, but probably doesn't need much benchmarking, and would depend on not only what chip, but what memory, what flash wait states/what cpu core clock, what caches are enabled, that sort of thing
<cr1901>
hmmmm
<re_irc>
< (@therealprof:matrix.org)> I'm totally fine with KISS and upholding the only guarantee we're currently giving.
<re_irc>
< (@chrysn:matrix.org)> > what caches are enabled
<re_irc>
I have vague memory of instruction times depending on how the code happens to be aligned across memory pages, I can ask a colleague about whether that was the conclusion of his M7 experiments.
<re_irc>
< (@adamgreig:matrix.org)> yea, I think I phrased this poorly, I also like upholding the current guarantee, I just wonder if we should change the actual timing back to 1x for most cores
<re_irc>
< (@adamgreig:matrix.org)> : I've definitely seen this effect even for like 128-byte flash read line alignment
<re_irc>
< (@adamgreig:matrix.org)> or 128-bit*?
<re_irc>
< (@therealprof:matrix.org)> That delay is never going to be better than a "wet finger in the air" anyway so the wetness of the finger shouldn't make any difference...
<re_irc>
< (@dkhayes117:matrix.org)> I like 1x for most cores
<re_irc>
< (@chrysn:matrix.org)> : IIRC this was about factor-of-4-ish. (I don't know what the dynamics of your finger are).
<re_irc>
< (@adamgreig:matrix.org)> nevertheless, it used to be 1x, and for most people on smaller cm0-4 cores, it did get 1x, enough that people opened bug reports when it was changed to be better on cm7 https://github.com/rust-embedded/cortex-m/issues/325
<re_irc>
< (@therealprof:matrix.org)> : Well, I'd rather have it 1x on all cores. If this is used for e.g. initialisation (as it is meant to be!) then it doesn't matter if a slower core is twice the amount of time it is required to wait.
<re_irc>
< (@adamgreig:matrix.org)> I think the only downsides of reverting to 1x on cm0-4 is that 1) people's delays change _again_, sigh, to get a bit longer, and 2) cm7 is even more wrong than it already is, but it's already pretty far wrong
<re_irc>
< (@adamgreig:matrix.org)> : i.e., increase the time even more so it's 1x on cm7 and 3x on cm0-4?
<re_irc>
< (@therealprof:matrix.org)> Why not keep it close to 1x for CM0-3 and have a different implementation for CM4 and higher?
<re_irc>
< (@adamgreig:matrix.org)> sadly we don't know the core at compile time, so we could have one impl for armv6 and another for armv7 and armv8, and cm3/4 cores would be at 3x while cm0/1 and cm7 would be at 1x
<re_irc>
< (@adamgreig:matrix.org)> I guess at the margin that is better
<re_irc>
< (@adamgreig:matrix.org)> but a bit annoying
<re_irc>
< (@therealprof:matrix.org)> Don't we have the target architecture at compile time?
<re_irc>
< (@therealprof:matrix.org)> I thought the only issue was that M4/M7 and some newer ones use the same target?
<re_irc>
< (@adamgreig:matrix.org)> but cortex-m0 and cortex-m1 are armv6-m, cortex-m3/4/7 is armv7
<re_irc>
< (@adamgreig:matrix.org)> the architecture does not map well to "how many clock cycles per instruction"
<re_irc>
< (@thejpster:matrix.org)> Sorry I was out. I have two things to say.
<re_irc>
Bogomips.
<re_irc>
And
<re_irc>
Just fix it in the documentation. No one cares what the number is, just that it delays it enough. If you just, provide a const scale factor for each core you know about. But donβt change the existing behaviour.
<re_irc>
< (@thejpster:matrix.org)> * must,
<re_irc>
< (@adamgreig:matrix.org)> people care enough that we've had bug reports opened in both directions after it was changed
<re_irc>
< (@therealprof:matrix.org)> Don't say Bogmips unless you mean it!
<re_irc>
< (@adamgreig:matrix.org)> well, we're out of time for this week and I have to finish on time today π
<re_irc>
< (@adamgreig:matrix.org)> I'll write up some options, I feel like this discussion possibly got a bit overboard for what I hoped would be less controversial
<re_irc>
< (@therealprof:matrix.org)> * Bogomips
<re_irc>
< (@therealprof:matrix.org)> : I agree, but I was hoping we could make it 1x or more without that meaning that the weakest of the weakest have to jump to 4x or worse.
<re_irc>
< (@jannic:matrix.org)> : Of course people complain when the docs say "at least n clock cycles" and that's actually not true. But if the docs were changed to "n/2 loops of this assembly loop" or whatever, I don't expect people to complain. Am I too optimistic?
<re_irc>
< (@adamgreig:matrix.org)> the docs said "Blocks the program for _at least_ "cycles" CPU cycles." and people complained when the actual number changed
<re_irc>
< (@adamgreig:matrix.org)> and other people rightfully complained that it still wasn't true on the cm7, after the change to try and make it true, so
<re_irc>
< (@adamgreig:matrix.org)> (changed from 1x to 1.5x "cycles" cycles)
<re_irc>
< (@adamgreig:matrix.org)> so yea, I think either way the docs should be improved
<re_irc>
< (@adamgreig:matrix.org)> ok, I have to run, thanks all! I will try and summarise some options for it in a little PR or RFC or something and we can discuss further there if need be
<re_irc>
< (@therealprof:matrix.org)> : I had to double check to make sure but actually M3 is ARMv7-M but M4 is ARMv7E-M, some of the newer cores are ARMv8-M so we have some wiggle room for multiple implementations where it makes sense. I'd rather pessimize only M4 to cater for M7 (and potentially newer/higher) rather than hitting M0/M3 and other lowly ones really hard.
<re_irc>
<sekoia> Heya, I'm starting out with embedded rust.
<re_irc>
I would like to do effectively, an hourglass, and here's how I was thinking of doing it:
<re_irc>
- the main loop checks for inputs such as pausing (I'd be using an active sensor, so I'd switch to a low-power mode which reads every ~5s or so instead of constantly polling a button
<re_irc>
- an interrupt timer would trigger once per minute, ticking down the timer. When paused, it wouldn't tick down.
<re_irc>
<sekoia> (sorry, what do those reactions mean?)
<re_irc>
< (@9names:matrix.org)> The reactions are a bot copy+pasting a large message to IRC, you can ignore them
<re_irc>
<sekoia> Ah, okay, thanks!
<re_irc>
<sekoia> Heya, I'm starting out with embedded rust.
<re_irc>
I would like to do effectively, an hourglass, and here's how I was thinking of doing it:
<re_irc>
- the main loop checks for inputs such as pausing (I'd be using an active sensor, so I'd switch to a low-power mode which reads every ~5s or so instead of constantly polling a button
<re_irc>
- an interrupt timer would trigger once per minute, ticking down the timer. When paused, it wouldn't tick down.
<re_irc>
<sekoia> Heya, I'm starting out with embedded rust.
<re_irc>
I would like to do, effectively, an hourglass, and here's how I was thinking of doing it:
<re_irc>
- the main loop checks for inputs such as pausing (I'd be using an active sensor, so I'd switch to a low-power mode which reads every ~5s or so instead of constantly polling a button
<re_irc>
- an interrupt timer would trigger once per minute, ticking down the timer. When paused, it wouldn't tick down.
<re_irc>
< (@therealprof:matrix.org)> sekoia: The most annoying thing of the Mutex dance is the amount of typing. Criticial Sections are somewhat cheap but they mess with the timing of interrupt handlers so they're frowned upon. If you don't like smell of this approach, there're better approaches available with use interrupt priorities to guarantee exclusive access to shared data, cf. RTIC. And of course there's the all new fancy...
<re_irc>
... approach using embassy.
<re_irc>
< (@therealprof:matrix.org)> * which
<re_irc>
<sekoia> Thanks, do you have some links for RTIC/embassy?
<re_irc>
< (@datdenkikniet:matrix.org)> also #rtic:matrix.org (https://matrix.to/#/#rtic:matrix.org) and #embassy-rs:matrix.org (https://matrix.to/#/#embassy-rs:matrix.org) :D
<re_irc>
<sekoia> Oo, thank you!
<re_irc>
<sekoia> Embassy seems really nice, esp. since they do have a HAL for my microcontroller... Thanks!
<re_irc>
< (@rursprung:matrix.org)> : if you create a release for it on GitHub it'll show up more prominently for your watchers and other people (e.g. in the "for you" feed).
<re_irc>
(cargo-release (https://crates.io/crates/cargo-release) has a pattern defined for how to create tags (and accordingly GH releases) for multi-crate repositories, you might want to follow that since so far you've only created GH releases for c-m but not the other crates in this repo)
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
<re_irc>
< (@rursprung:matrix.org)> : i've been doing embedded rust development for a good half year now (and rust for several years) and this is the first time i've ever seen either of these links π¬