<thejpster[m]>
I guess it speaks to the discoverability of those resources
jason-kairos[m] has joined #rust-embedded
<jason-kairos[m]>
Are there any resources for stack unwinding from within the firmware of a cortex M series MCU? (with the goal being to narrow down which thread paniced or hardfaulted and where)
<jason-kairos[m]>
I'm particularly interested in looking at the addresses of the functions and the stack pointer.
diondokter[m] has joined #rust-embedded
<diondokter[m]>
jason-kairos[m]: You mean, you want the unwinding to happen on the target?
<jason-kairos[m]>
Yeah
<jason-kairos[m]>
hmm.... now that I think about it, maybe the target wouldn't be able to know which registers got saved
<diondokter[m]>
You won't have debug info, so it
<diondokter[m]>
* so it's of limited use
<jason-kairos[m]>
I'm fine with not having functions names and whatnot if it is possible (I'm not sure it is)
<diondokter[m]>
You should be able to unwind and end up with with the program counters of each stackframe
<diondokter[m]>
Although... You won't really know about the stack
<diondokter[m]>
So you'd need frame pointers enabled
<thejpster[m]>
are frame pointers sufficient?
<thejpster[m]>
like, the return address is in LR, which sometimes gets pushed to the stack. If it did get pushed, where did it get pushed?
<diondokter[m]>
thejpster[m]: I've not used them, so I don't know the details.
<thejpster[m]>
I don't know that EABI requires I push stuff in a specific order. Only that I put everything (excluding the callee-saved registers) back as it was when a function exists.
<thejpster[m]>
s/exists/exits/
<jason-kairos[m]>
I'm really not sure that frame pointers are a thing on the cortex-M compiler abi
<jason-kairos[m]>
* compiler abi after reading that email chain
<diondokter[m]>
All I can find is that on thumb, the are stored in R7
<thejpster[m]>
yes but I don't think they are useful without debug info
<JamesMunns[m]>
we made them always-on to help with probe-run
<jason-kairos[m]>
What do you mean not useful without debug info?
<thejpster[m]>
I suppose if you have a disk drive you could put the debug symbols onto the disk and unwind the stack on the MCU using those. Sounds like a nightmare‡ though.
<JamesMunns[m]>
I think the plan was to follow the linked list back and just get the program counter at each of the stack frames?
<JamesMunns[m]>
you won't get function names, but you can get a list of pc addrs on the way back down. it's not useful for *recovery*, but maybe useful for *debugging*
<jason-kairos[m]>
JamesMunns[m]: Yes, and the stack pointer - to determine what thread crashed
<diondokter[m]>
Do you mean thread thread?
<thejpster[m]>
> the highest addressed word shall contain the value passed in LR on entry to the current function
<thejpster[m]>
Well if the frame record does contain LR, maybe that is sufficient
<jason-kairos[m]>
diondokter[m]: Yes I'm talking about real threads and RTOS etc.
<diondokter[m]>
My guess is you're in a hardfault and want to know from where you came, right?
<diondokter[m]>
Can't you just query the RTOS?
<jason-kairos[m]>
Hardfaults are not a problem
<jason-kairos[m]>
Panic handlers are a problem, they don't work in a way that is convenient by default
<diondokter[m]>
You can also look at just the current SP, right? Unless you stackoverflowed that should already tell you which thread you belong to
<jason-kairos[m]>
It can be hard to know who caused a panic (without error message) after optimizations
<jason-kairos[m]>
But yes, SP or a kernel syscall from a panic hook would get me which thread
<jason-kairos[m]>
but not necessarily anything more
<diondokter[m]>
Ah ok, so you want to know more than just knowing the thread
<jason-kairos[m]>
* know who (or more importantly what) caused a
<diondokter[m]>
Capture memory -> send to PC -> get a stack trace there
<jason-kairos[m]>
that's interesting
<diondokter[m]>
(I don't know how well it works right now as rustc has been updated a bunch since I last touched this)
<diondokter[m]>
(but I might work on it again for a client)
<diondokter[m]>
Haven't maintained it because people don't seem to be interested in using it :P
<jason-kairos[m]>
Yeah, core dumps (eg. to external flash) and debuggers cover a lot of the common usecases
<jason-kairos[m]>
I think I'm pretty much stuck with having lots of kind-of ambiguous panics - I know the debugger can't tell me very much, and the kernel can only add a little bit of information
<jason-kairos[m]>
A dozen little papercuts.
<diondokter[m]>
For your own code, know you can add #[track_caller] to functions
<jason-kairos[m]>
I've never heard of #[track_caller] - I need to look it up
<jason-kairos[m]>
(This sort of magic is what makes places like this invaluable)
<diondokter[m]>
Yeah, so get the panic location of the function caller instead of within the function
<diondokter[m]>
Really helped the unwrap functions so you get the place where unwrap was called instead of the line inside the unwrap function
<diondokter[m]>
It follows the chain up too
<jason-kairos[m]>
initially I want thinking knowing just the topmost caller was not enough, but you've got me thinking that maybe it is sufficent
<jason-kairos[m]>
Sometimes you've got a third party library for something like a buffer, that gets used in a million places. In those cases knowing who called it 3 levels down (or whatever) is useful
<diondokter[m]>
Yeah, but you can only add it your own code
<diondokter[m]>
(Or send patches to 3rd party code)
<jason-kairos[m]>
Wait, are you saying track_caller can be chained?
<diondokter[m]>
Yeah
<diondokter[m]>
But you'll only see the topmost caller
<jason-kairos[m]>
oh... I was really exited there for a moment.
<jason-kairos[m]>
Does track caller propogate downwards into calls that might panic?
<jason-kairos[m]>
eg. call third pary library
<diondokter[m]>
Nope
<diondokter[m]>
That's what I mean with that you can only add it to your own code
<jason-kairos[m]>
ie. it only affects panics in that specific function, but not calls made from it. Ok
<jason-kairos[m]>
Since I didn't know about #[track_caller] - are there any other tricks for modifying the behavior of panic!() and adding additional context information (other than adding an explicit error message, especially when calling third party functions)
<diondokter[m]>
That's the only one that comes to mind
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
What would it take to get syntax parity between defmt and std, for the most common operations. For example: floating point decimals, 0-padding, UTF-8-to-letters, and {var} syntax?
<firefrommoonligh>
I remember some chat here a few days ago about improvements to defmt, so thought it might be feasible
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
> What would it take
<dirbaio[m]>
it'd take sending a few PRs
<dirbaio[m]>
🙃
sroemer has quit [Quit: WeeChat 4.5.2]
oddlama[m] has joined #rust-embedded
<oddlama[m]>
Can someone advise me about how I should treat DelayNs?
<oddlama[m]>
I have several sensor objects which occasionally need to wait. What I've been doing so far is to give any method that might need to issue a delay a generic mutable delay like `fn something<D: DelayNs>(&mut self, &mut D)`, but with many methods this seems very boilerplate-y to pass a delay to each call.
<oddlama[m]>
Is it okay to give each objects its own owning DelayNs instance when constructing it? I'm sure it would work for the hal implementatinos I'm familiar with, but I'm not sure if this is generally a good thing to do.
<oddlama[m]>
* Is it okay to give each object its own owning DelayNs instance when constructing it? I'm sure it would work for the hal implementations I'm familiar with, but I'm not sure if this is generally a good thing to do.
<dirbaio[m]>
The recommendation is for hals to make the object cloneable yes
<oddlama[m]>
Ah perfect!
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
Regarding our talk yesterday about turning rust-embedded.org into a landing page, I've put some notes down. This is currently just a loose collection of what came into my mind and in no way complete. But maybe people here can have a look if that goes into the right direction. Here it is: https://gist.github.com/sourcebox/c5eefee9ae2da23034e252514565393e
<firefrommoonligh>
Free-standing delay fn is easier
<firefrommoonligh>
So you are not passing around the D, if you will
<firefrommoonligh>
;)
RockBoynton[m] has joined #rust-embedded
<RockBoynton[m]>
<oddlama[m]> "Is it okay to give each objects..." <- this is fine, although I would just say be wary of using blocking delay implementations for your driver within async tasks, this has bit me several times. Both embassy timers and rtic monotonics have clone/copyable delay instances. If you do use blocking implementations, make sure it is relatively short (10s of ms or less)
<oddlama[m]>
<RockBoynton[m]> "this is fine, although I would..." <- I'm working on a framework to define device drivers, so I don't know which implementation will be chosen by the user
<oddlama[m]>
I'm currently requiring embedded_hal_async::delay::DelayNs for async drivers and embedded_hal::delay::DelayNs for sync drivers
<oddlama[m]>
So I hope there are no blocking drivers implementing the former trait
<oddlama[m]>
* So I hope there are no blocking delay providers implementing the former trait
<jason-kairos[m]>
That is better, I should do that.
<jason-kairos[m]>
I probably could drop the write= as well
<jason-kairos[m]>
error: cannot use register `r12`: high registers (r8+) can only be used as clobbers in Thumb-1 code
<dirbaio[m]>
wtf
<dirbaio[m]>
are you really using thumb-1 though?
<dirbaio[m]>
I think all cortex-msomething are thumb2
<jason-kairos[m]>
it complains that I'm not using thumb-1. Since I'm using thumb2 it won't let me do in("r12") but it will let me do foo=In(reg) and assign it to R12 manually using the mov instruction
<dirbaio[m]>
ah lol I read the error message the wrong way round
<jason-kairos[m]>
I honestly don't understand why using r12 is an error.