<re_irc>
<Lachlan> Has anyone used "cargo-call-stack" within a workspace? I keep getting "error: Parse: missing field "package`
<re_irc>
<Lachlan> Was getting stack overflows in debug mode, turns out "array::map" was duplicating arrays like crazy
<re_irc>
<Lachlan> Was turning a stack frame with a few hundred bytes into more than 100 KB
explore has quit [Quit: Connection closed for inactivity]
GenTooMan has quit [Ping timeout: 264 seconds]
dc740 has joined #rust-embedded
GenTooMan has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
<re_irc>
<James Munns> Lachlan: FWIW, unless you're actually debugging in GDB or something, I typically run everything on embedded in release mode
<re_irc>
<James Munns> Even if you are, it's often pretty useful to set opt-level=1, because things like un-inlined function calls get pretty gnarly with deep call stacks
<re_irc>
<9names (@9names:matrix.org)> what's the default on debug mode?
<Lumpio->
Well yeah, because it's easiest to debug that way
<Lumpio->
Because every operation is there more or less as you wrote it
<re_irc>
<Abhishek Dhamale> Hello All, we are working on project where we are providing support for different development boards and each board has different dependencies. While compiling we are getting conflict for crate versions for different boards. So please suggest some example to configure cargo.toml file to avoid crate version conflicts.
<re_irc>
<9names (@9names:matrix.org)> "more or less" is very load-bearing in that statement
<Lumpio->
yes heh
<Lumpio->
I mean usually it's pretty close.
<Lumpio->
All your significant lines are there so you can step by line, all your function calls are there so you can step in/out, all your variables are there to inspect etc
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
rardiol has joined #rust-embedded
<re_irc>
<9names (@9names:matrix.org)> this actually leads into something I was already thinking about: what do folks typically use as their debug opt-level for embedded?
<re_irc>
O1 seems to be not too terrible for breakpoint debugging.
rardiol has quit [Ping timeout: 240 seconds]
<re_irc>
<James Munns> tbh, 99.9% of the time I just use probe-run, with opt-level 3/s
<re_irc>
<James Munns> I feel like every time I DO use GDB, it ends up segfaulting like every 30m (gdb itself, not my program)
<re_irc>
<mabez> James Munns: Maybe I should try this 🤔, like you said debugging release builds in GDB is horrific, I tend to get segfaults far sooner than 30mins in 😂
<re_irc>
<James Munns> I dunno, I tend to do "raw hardware driver dev" in simple standalone binaries that just exercise that, which I can run and re-run programs super quick in
<re_irc>
<James Munns> then turn that into a library, make sure it works, then just live in "happy rust land" from there.
<re_irc>
<James Munns> so I don't end up debugging a LOT "in place" in more complicated examples
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
<re_irc>
<9names (@9names:matrix.org)> > 99.9% of the time I just use probe-run, with opt-level 3/s
<re_irc>
same, that's why I'm asking!
<re_irc>
<9names (@9names:matrix.org)> i assume that at least "someone" uses breakpoint debugging and has some insight here, beyond the obvious "don't use opt-level 3/s or 0"
<re_irc>
<James Munns> Honestly, that's as deep as my advice goes, and matches my practice :p
<re_irc>
<James Munns> the other trick is to use profile overrides for individual crates, for example if you are debugging a HAL or PAC, you can build the REST of your application in opt level 3, but leave that one component at opt-level 0/1
<re_irc>
<James Munns> But like, this wouldn't have helped Lachlan's case, where one crate not being optimized (in particular, the main crate, I'm guessing) was enough to blow the stack
<re_irc>
<clifonlintic> I will only help 10 individuals
GenTooMan has quit [Ping timeout: 244 seconds]
rardiol has joined #rust-embedded
GenTooMan has joined #rust-embedded
<re_irc>
<Lachlan> Not the main crate actually, so we could turn on optimizations for it specifically. We usually do turn on at least opt-level 1, but it’s frustrating for half the stuff to be optimized out when debugging
<re_irc>
<Lachlan> And yeah, gdb crashes every other time. Amazing how bad it is
<re_irc>
<newam> What's the mode of failure with GDB?
<re_irc>
I have a list of bugs to fix myself, could add that to my todo list if it is something minor.
<re_irc>
<Lachlan> We’ve never looked further into it afaik. There’s a bunch of stuff going on with gdb and openocd, so it’s definitely possible the issues lie in the interface or in openocd completely
<re_irc>
<newam> Mmmm that's interesting.
<re_irc>
The bugs I have found are mostly with DWARF parsing from proprietary compilers. The parser needs some fuzzing something awful
<re_irc>
<Lachlan> I’d love to see the probe-rs ecosystem extend into debuggers as well over time. I know headcrab was/is a thing, but not sure how far it got
<re_irc>
<K900> They're not _really_ RTOSes in the very traditional sense, but they're close
<re_irc>
<Jan Bronicki> so they privde basically the scheduling part?
<re_irc>
<Jan Bronicki> whats the diff between them and eg FreeRTOS?
<re_irc>
<K900> They use Rust async instead of building a custom task scheduler abstraction
<re_irc>
<Jan Bronicki> well
<re_irc>
<Jan Bronicki> isnt that a good thing?
<re_irc>
<Jan Bronicki> after all the end result is basically the same right?
<re_irc>
<K900> Yes and no
<re_irc>
<K900> It makes some things easier, and it makes other things somewhat harder
<re_irc>
<K900> But you can get the same results out of them
<re_irc>
<Jan Bronicki> okay thats what i mean
<re_irc>
<Jan Bronicki> coz im getting back into embedded and currently at my science club the team i joined is making a logger on a stm32f4 for a rocket
<re_irc>
<Jan Bronicki> and its currently being done in C++
<re_irc>
<Jan Bronicki> but later i would like to rewrite it in rust as an excercise so im just wondering if its possible
<re_irc>
<Lachlan> Definitely is
<re_irc>
<Lachlan> I wrote the firmware for the logging and control electronics on my university’s liquid rocketry student team in rust
<re_irc>
<Jan Bronicki> nice
<re_irc>
<Jan Bronicki> you know i just really want it to basically be the same product but just written in rust
<re_irc>
<Lachlan> That depends on what the current product is
<re_irc>
<Lachlan> I wouldn’t recommend mixing freertos and rust for example