<JamesMunns[m]>
it was I think intended to be a way to define the program's entrypoint, but it didn't really pan out, and embedded all uses #![no_main] anyway these days, which did stabilize
<JamesMunns[m]>
a bit of docs ^ there, and it is discussed a bit at the top of the issue
<JamesMunns[m]>
it's being nominated for removal because it doesn't really do what anyone wants these days
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
It doesn't look like I've ever used it for anything. I found one RFC that mentions #[main], but I can't remember where else I've seen that before either.
<bartmassey[m]>
I think our #[entry] is just a name that matches with our linker script, yes?
<JamesMunns[m]>
yep, we do no_main, then cortex-m-rt (or other -rt crates) will do a jump to no_mangle'd symbol
<JamesMunns[m]>
* jump to a no_mangle'd symbol, * no_mangle'd symbol, usually from asm
<berkus[m]>
Yep, usually just making a no mangle fn and say its name in the linker script. There arent any standardized args to that fn anyway.
<berkus[m]>
JamesMunns[m]: And it cannot into argument quoting in the url, nice
<diondokter[m]>
Ha, the serde no_std test uses it apparently!
<berkus[m]>
Holding spacebar
<bartmassey[m]>
Offtopic, but that code search is hilarious. Try 'PERFORM VARYING d FROM 1 BY 1 UNTIL d > 3'
<bartmassey[m]>
Computers are weird.
crespum[m] has quit [Quit: Idle timeout reached: 172800s]
mkj[m] has joined #rust-embedded
<mkj[m]>
<berkus[m]> "Yep, usually just making a no..." <- it's annoying that `no_mangle` prevents `forbid(unsafe)`. so it'd be nice to have _some_ way to do that
JulianDickert[m] has quit [Quit: Idle timeout reached: 172800s]
<hjeldin__[m]>
quick question: should opt-levels have any side effect on the code? if i remove opt-level = 'z' my display driver no longer works, which is weird since i was under the impression that, if anything, it shouldn't work with the optimizations enabled.
<JamesMunns[m]>
<hjeldin__[m]> "quick question: should opt-..." <- Do you have any unsafe in your code? "Behavior changes with opt levels" is usually either "undefined behavior" or "timing issues"
<hjeldin__[m]>
not that i wrote, no
<JamesMunns[m]>
So when you say "remove", you mean still in release mode?
<JamesMunns[m]>
(if you remove it, it goes to opt level 3)
<hjeldin__[m]>
yep, i guess it default to something else
<JamesMunns[m]>
s/goes/defaults/
<hjeldin__[m]>
right, and opt level 3 is "less" optimized than "z", correct?
<JamesMunns[m]>
Not really
<JamesMunns[m]>
3 is more "aggressive", but z can sometimes be faster as it tends to produce smaller code
<JamesMunns[m]>
s/z/3 are kind of all "better in different situations" and might all be smaller/faster depending on different optimization settings and thresholds
<hjeldin__[m]>
i'll try opt-level 1 then
<JamesMunns[m]>
If you can share the whole project as a GitHub repo I can take a peek, but it's likely either timing issues or undefined behavior in your dependencies
<JamesMunns[m]>
Or, could be a stack overflow, that's the third most likely cause of issues like this
<JamesMunns[m]>
That can be tested by using flip-link in most cases, if you have a single core target
<hjeldin__[m]>
speaking of flip-link, if i add it to my dependencies i'm no longer able to compile 🥲
M9names[m] has joined #rust-embedded
<M9names[m]>
are you following all of the instructions given in the readme?
<thejpster[m]>
cargo nbuild will be able to compile the OS, compile and link all the utilities, build a ROMFS, and then link an OS image containing that ROMFS.
<thejpster[m]>
something something workspace mixing native and cross-compiled no_std things something
<hjeldin__[m]>
JamesMunns[m]: it's a stm32l476rg on a nucleo board
<JamesMunns[m]>
yeah, I'd try adding that to the runner command in your .cargo/config.toml and see if that helps
<hjeldin__[m]>
thanks!
<hjeldin__[m]>
yup, it works, thanks!
<JamesMunns[m]>
<hjeldin__[m]> "alright, i edited some code..." <- all of timing, ub, and stack overflow can be sensitive to small changes in the code, if you're right on the edge. It's all kinda dependent on what the optimizer does
<hjeldin__[m]>
if it's a stack overflow shouldn't i see a panic tho?
<dirbaio[m]>
because the self import imports only the module, not the macro.
<dirbaio[m]>
💩!!!!!
<thejpster[m]>
Oh no
<thejpster[m]>
Macro imports in Rust are such a mess. It should have been use foo::bar!.
flippette[m] has joined #rust-embedded
<flippette[m]>
thejpster[m]: kinda out of place for attr macros though
<thejpster[m]>
True
<JamesMunns[m]>
<hjeldin__[m]> "if it's a stack overflow shouldn..." <- Not necessarily, unless you are using flip-link. Stack overflows can just silently corrupt data, causing the system to sort of work, not work at all, or whatever other generally "there be dragons" behavior you can or can't imagine.
<hjeldin__[m]>
gotcha
<JamesMunns[m]>
flip-link makes it so that a stack overflow causes a hard fault, which should cause an exception to occur, and this can be seen with probe-rs
<thejpster[m]>
not helped by the windows runner taking five times as long as the linux runner
Makarov has quit [Quit: Client closed]
Makarov has joined #rust-embedded
Makarov has quit [Ping timeout: 240 seconds]
norineko has quit [Remote host closed the connection]
chrysn[m] has joined #rust-embedded
<chrysn[m]>
Around defmt, I'm currently logging a lot of CBOR. I understand that defmt can't reasonably carry type information across, but would it make sense to allow a hint (eg. {=u8:cbor}) through which the decoder would know that the data in there is CBOR, and should be passed through a diagnostic formatter for human readability?
norineko has joined #rust-embedded
<chrysn[m]>
(Right now what I do is pack a :02x in, and copy-paste the dumps to https://cbor.me/)
<diondokter[m]>
What's the easiest way to convert hex-formatted bytes (machine code) to readable thumbv7 asm code?
<diondokter[m]>
Oh! Maybe I can hand it to objdump?
<chrysn[m]>
I think it's objcopy
<diondokter[m]>
That might work too...
mchodzikiewicz[m has joined #rust-embedded
<mchodzikiewicz[m>
hi, quick defmt question - in struct you want to derive Format, can you skip a field that doesn't implement it but you don't care? (it doesn't implement Display or Debug either)
<bitts[m]>
<chrysn[m]> "Around defmt, I'm currently..." <- Could you just wrap it in a Struct and then implement defmt::Format manually?
<chrysn[m]>
Thing is, the data is in a quite good shape to be copied over the wire with zero need to process it.
<chrysn[m]>
Sure, I could hook up a generic CBOR decoder and diagnostic notation generator, but then that'd need to run on the microcontroller and emit a bunch of "{", ":", "," etc characters (only saving on numbers because they don't have to be converted to ASCII decimal), but diagnostic notation is really not something meant for embedded systems, it is meant to be translated at the powerful display.
<bitts[m]>
Agreed, =u8:cbor would be neat. The quicker solution is maybe to use the --json output and pipe it to your own formatter
<diondokter[m]>
<diondokter[m]> "What's the easiest way to..." <- Ok, an answer is to make the bin/hex into an elf using objcopy and then use rust-objdump with the `--triple` argument to specify the target
<dirbaio[m]>
<diondokter[m]> "Ok, an answer is to make the bin..." <- Load it into Ghidra :D
<diondokter[m]>
I wanted easy :P
danielb[m] has joined #rust-embedded
<danielb[m]>
are you decompiling the loader to find clues, or are you comparing it to the source? fun fact, there was a new U0 pack release on the 18th