06:23 <re_irc> <Yuhan Lin> cr1901: Is it possible to run "compilefail" tests for "msp430-rt" the same way it's done for "cortex-m-rt"? I tried setting it up but Xargo can't build "compilefail" at all and the Cargo can't build the main crate.

10:24 <cr1901> Yuhan Lin: I'm not sure what's wrong w/ the msp430-rt docs I'm afraid. I'll take a look this weekend or early next week

10:24 <cr1901> Today is not going to be a good day to look at it; docs build fine for me locally when I pass --target=msp430-none-elf -Zbuild-std=core

12:39 <re_irc> <dirbaio> ghidra now explodes while loading rust ELFs? "Error during DWARFAnalyzer import: ghidra.app.util.bin.format.dwarf4.DWARFException: Only DWARF version 2, 3, or 4 information is currently supported."

12:52 <re_irc> <adamgreig> rust's too secure for the nsa 🔒️

12:54 <re_irc> <dirbaio> it seems it's now generating DWARFv5 by default..?

12:55 <re_irc> links to a commit, but it's clang, not llvm, not sure why/how that affects rustc

12:55 <re_irc> <dirbaio> there's this https://github.com/rust-lang/rust/issues/75890

13:01 <re_irc> <dirbaio> either way I can't recompile, this is when trying to debug a crash from a device in the field lol

13:01 <re_irc> <dirbaio> I got a register/stack dump... addr2line outputs nonsense, ghidra won't load the elf... yay

13:02 <re_irc> <adamgreig> tried radare2/cutter?

13:03 <re_irc> <dirbaio> could try yep

13:05 <re_irc> <dirbaio> I got defmt logs too, but they show no clue because "regular" panics like .unwrap() or array indexing aren't logged

13:05 <re_irc> <dirbaio> (you can log them to defmt if you opt-in to core::fmt bloat which defeats the point of defmt)

13:05 <re_irc> <dirbaio> it'd be amazing if there was a way to get these logged without bloat >_<

13:06 <re_irc> <dirbaio> even if forking libcore or whatever

16:43 <re_irc> <diondokter> Is "#[no_mangle]" still the only/best way to keep data around even the the compiler thinks it isn't used?

16:43 <re_irc> That is what the cortex-m-rt crate does with the vector tables, but this suggests that it isn't a good way: https://internals.rust-lang.org/t/precise-semantics-of-no-mangle/4098

16:43 <re_irc> #[link_section = ".spm"]

16:43 <re_irc> For my specific usecase, I'd like to include another program in my program. This works:

16:43 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/cb7e33e6492f1ff4a8ed601d4f7bb15e60c368cdc9b7924f7f807dc20b375922 (10 lines)

16:50 <re_irc> <dirbaio> there's also "#[used]"

16:51 <re_irc> <dirbaio> I have both "#[used]" and "#[no_mangle]" in a similar usecase, I'm not sure if "#[used]" is enough to get it to not optimize it out.. :S

16:52 <re_irc> #[used]

16:52 <re_irc> #[link_section = ".softdevice"]

16:52 <re_irc> <dirbaio> #[cfg(feature = "softdevice")]

16:52 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/4adab1c312ccb21b0e90eb20c1e07d4e04b8c4e7d0eee71b0b06f2efb1aa28fc (6 lines)

16:52 <re_irc> #[no_mangle]

16:52 <re_irc> <diondokter> Hmmm I can try next time

16:52 <re_irc> <diondokter> Thanks!

16:52 <re_irc> <dirbaio> plus "include_bytes!" twice to avoid having to hardcode the length D:

16:52 <re_irc> <dirbaio> * :D

16:52 <re_irc> <diondokter> Ah right

16:52 <re_irc> <diondokter> :P

16:52 <re_irc> <dirbaio> 🙈

16:54 <re_irc> <diondokter> Yeah, just using "#[used]" seems to do the trick!

16:54 <re_irc> I like this much better :)

16:54 <re_irc> <dirbaio> nice!

19:39 <re_irc> <gauteh> Are interrupts disabled if I do cortex_m::SCB::sys_reset()?

20:02 <re_irc> <adamgreig> as in, will any interrupts still be enabled after the reset? in which case no, the reset clears all enabled vectors in NVIC

20:03 <re_irc> <adamgreig> (sorry, I inverted your question: interrupts are all disabled after a reset until enabled by software, and the SCB sys_reset is the same as toggling nRST pin in this case)

20:03 <re_irc> <gauteh> Ok!

20:05 <re_irc> <gauteh> Thanks.

20:27 <re_irc> <omar_u8> I am getting a segmentation fault when trying to run an openocd session, any clues where I shoule be looking?

20:29 <re_irc> <omar_u8> I am getting a segmentation fault when trying to run an openocd session, any clues where I shoule be looking?

20:29 <re_irc> openocd -f interface/stlink.cfg -f target/stm32f4x.cfg

20:29 <re_irc> This is the output im getting

20:29 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/d8e3eba1da0f9546a27c17a6ae234545f31f2338a2f97c0d7b5d3d4a8d0743f5 (13 lines)

20:29 <re_irc> Open On-Chip Debugger 0.11.0

20:30 <re_irc> <omar_u8> * should

21:13 <re_irc> <9names (@9names:matrix.org)> Run openocd through gdb so you get a stack trace when it segfaults, search their GitHub issues for similar reports, make a new one if you can't find anyone with the same error.

21:19 <re_irc> <omar_u8> 9names: I’m sorry but I’m not sure how to do that in gdb. Though in general, when starting gdb I’ve tried connecting to target through gdb, I get a timeout.

21:30 <re_irc> <omar_u8> * gdb if you can please help.

21:37 <re_irc> <xiretza> omar_u8: "gdb --args openocd -f interface/stlink.cfg -f target/stm32f4x.cfg" should do it - then once in the gdb shell, type "run", wait until it segfaults, then look at the output of "backtrace full"

22:40 <re_irc> <9names (@9names:matrix.org)> Just in case it's not clear from the error messages: openocd is crashing, so you are using gdb here to debug openocd, not your embedded program.

22:43 <re_irc> <9names (@9names:matrix.org)> If you aren't up for that, you can also try using a different debug tool like probe-rs-debugger or pyocd to see if that helps.