crabbedhaloablut has quit [Ping timeout: 252 seconds]
limpkin has joined #rust-embedded
pcs38 has joined #rust-embedded
pcs38 has quit [Quit: leaving]
PhilMarkgraf[m] has quit [Quit: Idle timeout reached: 172800s]
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
<Ralph[m]>
reading the past few messages i wonder if it wouldn't be a nice bachelor/master thesis for someone to analyse and figure out the best way to optimize power consumption for various use-cases with embedded rust (and of course provide PRs to embassy, RTIC, etc. to make this easier). just putting this out there for the people in this chat which work at universities and might have the chance to actually float this as a thesis idea 😉
RobinMueller[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
Can / should we make the various WG teams into "Teams" within github.com/rust-lang? Then you could ping them with an @.
<jason-kairos[m]>
(In my case, I'm just trying to see the source of the panic handler for hubris)
<thejpster[m]>
hubris, IIRC, is an RTOS that compiles each task as a binary, links everything, works out how big it all is, then links it again with the perfect amount of memory allocated
<JamesMunns[m]>
workspace packages should follow profile.release settings
<jason-kairos[m]>
* for hubris, it can be built with different settings per binary)
<JamesMunns[m]>
thejpster[m]: yeah, it's possible they don't retain/preserve debuginfo correctly, but you'd have to open an issue with them
<thejpster[m]>
so, "binary" is complicated when talking about Hubris. Are you talking about the kernel, or a task, or the combination of the kernel and all the tasks?
<jason-kairos[m]>
When I debug, the binary is the combination. And I have to load in the debug symbols from the separate object files before it combines the two
<thejpster[m]>
in terms of panics, I expect each task to have its own panic handler, which reports to the kernel that the task did a panic. The kernel will then restart the task.
<jason-kairos[m]>
Yes, each one is unique. But lacking debug symbols.
<thejpster[m]>
I don't think you can load debug symbols from object files? The debugger will need to know which address each symbol has and object code is from before address allocation.
<thejpster[m]>
you could probably load debug symbols from the ELF file created for each task, as long as its from after the final memory allocation not before.
<thejpster[m]>
Sorry, I've never tried to do what you're doing so I don't have good answers.
<jason-kairos[m]>
That seems like a "simpler" problem - although, I confess I don't actually know how gdb finds/guesses the source code paths in the first place
<jason-kairos[m]>
For normal rust programs - isn't viewing dependency sources in the debugger also a "problem" ?
<thejpster[m]>
There are no dependencies any more once you have a binary. There are symbols, which have an address, and there is debug information which maps machine code addresses back to regions of source code.
<JamesMunns[m]>
<thejpster[m]> "See https://rust-training...." <- btw is there a reason you picked "Task" as a general term here, vs "threads" or "apps"? TockOS calls them capsules, zephyr calls them threads, rtems does seem to call them tasks, I think freertos might also call them tasks
<jason-kairos[m]>
hubris calls them tasks
<JamesMunns[m]>
<thejpster[m]> "See https://rust-training...." <- "Task" just has a different meaning in Rust, specifically.
<thejpster[m]>
James Munns: only that is the term I prefer to use.
<jason-kairos[m]>
that's going to make my debugging experience way more pleasant
<jason-kairos[m]>
and now single stepping actually takes me directly to the hubris userspace libraries that handle panicking (in a way that is configurable and possibly different per program)
<jason-kairos[m]>
thank you again everyone, I don't think I would have thought that of all things was the issue (I'd have thought that I could still breakpoint inside of userlib::panic without this)
<jason-kairos[m]>
* thank you again everyone, I don't think I would have suspect that this of all things was the issue (I'd have thought that I could still breakpoint inside of userlib::panic without this)
<jason-kairos[m]>
* thank you again everyone, I don't think I would have suspected that this of all things was the issue (I'd have thought that I could still breakpoint inside of userlib::panic without this)
SosthneGudon[m] has quit [Quit: Idle timeout reached: 172800s]
<jason-kairos[m]>
now that I think about it, it would probably have to be a macro. In which case, it's probably not worth the effort.
pcs38 has quit [Remote host closed the connection]
<thejpster[m]>
how do you mean optimised out? Arguments are passed by the caller, according to the parameter list, and I don't think there's anything a function body can do to stop a caller from passing them.
<thejpster[m]>
Unless it's all inlined, but you've expressly prevented that.
<jason-kairos[m]>
despite the #[inline(never)] and the body being just a asm::nop() gdb reports the arguments the to function being clobbered unless I specifically perform a read_volatile() on each function argument
<jason-kairos[m]>
(optimized out, not clobbered)
<jason-kairos[m]>
(ie. I set a breakpoint in gdb, and can't read the args)
<thejpster[m]>
Oh I see. I suspect they are there, gdb is just telling you they aren't. But if the function was non-empty, locals could be stored in whatever register was used to pass the arguments you aren't using.
<jason-kairos[m]>
You are right, sometimes. Other times, it almost seems like the compiler "knew" the arguments were not uses, and so nothing valid got passed into the registers to start with (I might be fooling myself, but I'm pretty sure I've seen it go both ways)
<jason-kairos[m]>
s/uses/used/
<jason-kairos[m]>
* You are right, sometimes. Other times, it almost seems like the compiler "knew" the arguments were not used, and so (seemingly) nothing valid gets passed into the registers to start with (I might be fooling myself, but I'm pretty sure I've seen it go both ways)
<thejpster[m]>
I would be surprised to find that call sites were being optimised based on the function being called (unless you are using LTO, in which case yeah, perhaps it can do that).
RobinMueller[m] has joined #rust-embedded
<RobinMueller[m]>
Who do I need to ping for MSP430 issues again? ^^ i found a really weird issue yesterday when using the 32bit multiplier support. I was wondering if anyone else has used it and encountered issues as well. I still need to compare the actual compiler output and create a clean minimum working example, but maybe i am not the first one..
<RobinMueller[m]>
* multiplier support via compiler flag. I
<JamesMunns[m]>
@cr1901
<RobinMueller[m]>
* multiplier support via compiler flag, leading to odd system behaviour/crashes. I
Amit[m] has quit [Quit: Idle timeout reached: 172800s]
MartinSivk[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has quit [Quit: WeeChat 4.4.3]
pcs38 has joined #rust-embedded
lanre[m] has quit [Quit: Idle timeout reached: 172800s]
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
newam[m] has quit [Quit: Idle timeout reached: 172800s]
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
burrbull[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
<RobinMueller[m]>
It's a MSP430FR5994, so I assumed 32bit mul support should work
ouilemur has quit [Quit: WeeChat 4.6.2]
ouilemur has joined #rust-embedded
pcs38 has quit [Quit: leaving]
<cr1901>
RobinMueller[m]: I don't think I've ever used the multiplier peripherals, opting for software mul; it may well be a backend bug. I'd need to see an MCVE
kit[m] has quit [Quit: Idle timeout reached: 172800s]