<re_irc>
<Julia> I'll be going to bed, but if anyone has an idea just ping me and I'll look at it tomorrow :)!
<re_irc>
< (@adamgreig:matrix.org)> you could try "list main.rs:17" and just see what it thinks is in main.rs I suppose, but otherwise it seems OK...
<re_irc>
< (@adamgreig:matrix.org)> I guess you could try "b /full/path/to/your/project/src/main.rs:25" just to be sure but I doubt it'l help
<re_irc>
< (@adamgreig:matrix.org)> oh, what directory are you in when you run gdb? the project directory?
<re_irc>
< (@adamgreig:matrix.org)> oh, yes, I see that you are from the console log. so that should be fine.
<re_irc>
< (@adamgreig:matrix.org)> I guess you could try "directory src" in gdb too just to be safe but again i doubt that's it...
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 260 seconds]
<re_irc>
<Julia> : I tried this as well before.
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
Lumpio- has quit [Ping timeout: 272 seconds]
Lumpio- has joined #rust-embedded
<re_irc>
< (@chrysn:matrix.org)> After one more time of going from "hey cool that crate is no-std" to "bah, looking at src/lib.rs its third line is "extern crate alloc"", I've gone ahead and opened https://github.com/rust-lang/crates.io/pull/5949
<re_irc>
< (@chrysn:matrix.org)> (Not shaming any crates here: Being no-std and just using alloc is IMO a mark of quality over crates that by default use std, and quite helpful. It's just not what I wanted to know, or what I need for my applications).
<re_irc>
<Julia> I tried using openocd as well for gdb and I get the same problem there, even if _load_ does work.
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
< (@ryan-summers:matrix.org)> +1 on no-alloc request. I haven't really had this issue, but that would definitely be a positive in my book. Lots of apps cant have (or dont want) an allocator
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
<re_irc>
<Julia> Okay interesting thing I found, I _can_ set breakpoints for lower values, but the numbers will be very very incorrect.
<re_irc>
<Julia> (gdb) b main
<re_irc>
(gdb) b 5
<re_irc>
Breakpoint 5 at 0x312: file src/main.rs, line 17.
<re_irc>
< (@dirbaio:matrix.org)> there's probe-rs-debugger, with the vscode extension
<re_irc>
< (@dirbaio:matrix.org)> it's built specifically for rust embedded so it might be better
<re_irc>
< (@dirbaio:matrix.org)> but... I recommend just debugging with prints 😂
<re_irc>
<Julia> I'm mainly just not sure _why_ it is not working.
<re_irc>
<Julia> Wouldn't these same issues happen with any debugger?
<re_irc>
< (@k900:0upti.me)> Not really
<re_irc>
< (@k900:0upti.me)> All the source visualization is done by the debugger itself
<re_irc>
< (@k900:0upti.me)> So it's possible gdb is just doing it wrong
<re_irc>
<Julia> So how does lldb work? Is it the same idea?
<re_irc>
< (@k900:0upti.me)> Yes
<re_irc>
<Julia> and probe-rs, does that allow me to use the commandline like gdb?
<re_irc>
< (@k900:0upti.me)> No, it speaks the VSCode debug adapter protocol
<re_irc>
<Julia> I don't have VSCode though, I use Clion 😅.
<re_irc>
< (@k900:0upti.me)> Most editors have plugins for it
<re_irc>
< (@k900:0upti.me)> Not sure if Jetbrains stuff does
<re_irc>
< (@ryan-summers:matrix.org)> probe-rs does have a gdb stub you can use
<re_irc>
< (@ryan-summers:matrix.org)> It's easiest-used through cargo-embed
<re_irc>
<Julia> Well that's what I have been doing 🙃
<re_irc>
<Julia> Has anyone actually ever successfully used gdb with rust on a non-emulated chip?
<re_irc>
< (@ryan-summers:matrix.org)> Sorry, only read the last like 3 messages
<re_irc>
< (@ryan-summers:matrix.org)> I use gdb all the time with firmware. I use it less nowadays since I find I need it far less with Rust
<re_irc>
< (@k900:0upti.me)> Julia: Yes, a lot
<re_irc>
< (@k900:0upti.me)> I feel like you're really underestimating how many people are using Rust
<re_irc>
< (@ryan-summers:matrix.org)> That being said, I have seen weird behavior with gdb+rust at times
<re_irc>
< (@k900:0upti.me)> It's not really a joke toy language for three nerds anymore
<re_irc>
< (@k900:0upti.me)> The answer to "has X ever been done in Rust" is basically always "yes"
<re_irc>
<Julia> Well I had some serious issues finding good gui libraries and cuda support. It's not there yet I think haha.
<re_irc>
< (@jamesmunns:beeper.com)> Chiming in with others, gdb is something I use when I have to, and it generally works... okay, I'm guessing it is not dealing with procedural macros here which are affecting the debuginfo, this totally could be a regression.
<re_irc>
That being said: 99/100 times I will use "probe-run" and get logging-style output instead of gdb's interactive debugger.
<re_irc>
< (@ryan-summers:matrix.org)> Rust does indeed not really have many good GUI libs. It's also not really intended to be a front-end language for many aspects
<re_irc>
< (@k900:0upti.me)> It may not be "there" in specific use cases, sure, but the embedded ecosystem is generally fairly mature
<re_irc>
< (@jamesmunns:beeper.com)> I generally ONLY use GDB when something has gone terribly wrong, and I'm probably going to be "si"'ing though the asm anyway to figure out why something isn't working.
<re_irc>
< (@k900:0upti.me)> I find lldb to generally be much less of a pain
<re_irc>
< (@ryan-summers:matrix.org)> I only use GDB when I need to start poking into register values nowadays. Otherwise, logging works great
<re_irc>
< (@k900:0upti.me)> Probably because it was built with multiarch support from the start
<re_irc>
< (@jamesmunns:beeper.com)> (if you want to test my hunch re: procedural macros, it'd be interesting if you move your whole "main" to a function in another file, that isn't inside the "#[entry]" macro, and see if GDB has a better time of setting breakpoints and stuff.
<re_irc>
< (@ryan-summers:matrix.org)> GDB's issue isn't really multiarch support, it's more the fact that it's really designed around C-like languages
<re_irc>
< (@jamesmunns:beeper.com)> so your main is just "other_file::other_main()"
<re_irc>
< (@ryan-summers:matrix.org)> So it's a bit unwieldy to use for Rust
<re_irc>
<rjmp> Julia: My experience is that it is OK with optimization off, and useful only just barely for checking hardware registers when optimization is on. Even global statics cannot typically be found. It is a frustration for me.
<re_irc>
<rjmp> ( usually my embedded applications are non functional with no optimization)
<re_irc>
< (@jamesmunns:beeper.com)> yeah, rust does have known deficiencies around producing/preserving good/reliable debuginfo with optimizations turned on, especially at higher levels
<re_irc>
< (@jamesmunns:beeper.com)> I've definitely turned optimizations on for all dependencies, for example, but leaving my main application opt-level = 0, so it's easier to debug
<re_irc>
< (@jamesmunns:beeper.com)> but then stepping into dependencies is... challenging.
<re_irc>
<Julia> : I don't quite follow, what would an "#[cortex_m_rt::entry]" achieve if there is nothing, will that even compile?
<re_irc>
< (@jamesmunns:beeper.com)> So, Julia, I don't think you're wrong/"holding it wrong"/"having unreasonable expectations" - I think a lot of us are just used to gdb being sort of unusable/not a great experience, and I would bet a lot of people don't use it as a first tool of choice.
<re_irc>
I'd say the "typical" debugging tool of choice is something like "probe-run" or "cargo-embed" using "defmt" or "rtt-target" for sending text-style debug messages over the debugger interface, rather than something interactive.
<re_irc>
< (@ryan-summers:matrix.org)> I 100% avoid GDB _much more_ in rust than in C or other languages, so I have a feeling James is right on the money with that one
<re_irc>
< (@ryan-summers:matrix.org)> That being said, I also noticed I need it far less as well
<re_irc>
<Julia> : Okay I did what you just suggested and it seems to set a breakpoint correctly now in main.rs, but it again _can't_ set a breakpoint correctly in other_file.rs
<re_irc>
< (@jamesmunns:beeper.com)> Okay, then I have no idea. That is in fact super weird.
<re_irc>
<Julia> This has been a very difficult introduction to embedded rust so far for me 🙃
<re_irc>
< (@jamesmunns:beeper.com)> : Seconding this, I find I don't need to go digging with the debugger to find why something didn't work, unless I'm debugging the hardware registers themselves, or some unsafe code that actually has undefined behavior
<re_irc>
<rjmp> I also agree that my rust code is more likely to be correct, but I would not say that I no longer want a debugger that works because of that! Its still useful to view states at different points. One can still make logic errors! I've been meaning to do a deeper dive on what's going on; I don't fully understand if this is a fundamental problem, or rustc just needs to generate better annations? Or what? I ended up leaning on...
<re_irc>
... prints as well, but I don't like it much.
<re_irc>
<Julia> It's a shame, maybe the debug section should be changed then in the Discovery book, because it straight up does not work as advertised.
<re_irc>
< (@ryan-summers:matrix.org)> I disagree, but you definitely need to know the "gotchas" like disabling optimizations and knowing how to set up probe-rs for gdb
<re_irc>
<rjmp> Julia: Your case does surprise me. Without optimizations ( and it sounds like you have then off) I would expect your use case to work. The problem with that strategy is that often things won't for in flash, or run too slow to work the same with hardware!)
<re_irc>
<rjmp> * hardware!
<re_irc>
<Julia> [profile.dev]
<re_irc>
strip = false
<re_irc>
codegen-units = 1
<re_irc>
opt-level = 's'
<re_irc>
lto = true
<re_irc>
< (@jamesmunns:beeper.com)> oh
<re_irc>
< (@jamesmunns:beeper.com)> ueah
<re_irc>
< (@jamesmunns:beeper.com)> * yeah
<re_irc>
< (@jamesmunns:beeper.com)> that opt level will definitely make debugging worse.
<re_irc>
< (@k900:0upti.me)> "opt-level = 's'" seems very unnecessary
<re_irc>
< (@jamesmunns:beeper.com)> "opt-level = 0" is going to be the best debugging experience.
<re_irc>
<Julia> (gdb) target remote:1337
<re_irc>
Dwarf Error: Cannot find DIE at 0xce15 referenced from DIE at 0x6cde [in module /home/julia/CLionProjects/nrf51822_blinky_rust/target/thumbv6m-none-eabi/debug/nrf51822_blinky_rust]
<re_irc>
Remote debugging using :1337
<re_irc>
<Julia> I tried this before and then I can't even connect anymore.
<re_irc>
<Julia> believe it or not I managed to fix it
<re_irc>
<Julia> there must be a bug with LTO = true
<re_irc>
<Julia> disabling it lets me set breakpoints
<re_irc>
< (@jamesmunns:beeper.com)> Good catch! I didn't think of that, but it makes sense.
<re_irc>
<Julia> I have no idea _why_ this works though again. LTO is just to make libraries reuse code more efficiently?
<re_irc>
< (@k900:0upti.me)> No
<re_irc>
< (@jamesmunns:beeper.com)> LTO is "link time optimization", which is doing whole-program (rather than crate-by-crate) optimization. I'm guessing our linker (llvm's lld) is doing _something_ in that optimization stage that makes debuginfo wrong
<re_irc>
< (@k900:0upti.me)> LTO can do a lot of things
<re_irc>
< (@k900:0upti.me)> And pretty much all of them will mess with the layout of the program in memory
<re_irc>
< (@jamesmunns:beeper.com)> LTO typically has a very positive impact to code size and speed, so you'll often see it turned on in Rust projects. But as K900 mentions, it can do a LOT, and doesn't seem to be very good at keeping the debuginfo correct in some (all?) cases.
<re_irc>
<Julia> Yeah I used it all the time before this for speed mainly.
<re_irc>
< (@jamesmunns:beeper.com)> this is one of those things that is a big deal for gdb, but wouldn't impact logging based debugging, like probe-run.
<re_irc>
< (@jamesmunns:beeper.com)> but if the discovery book doesn't mention these should be off (or tells you to turn lto/opt-level on), it could definitely be improved to help the next person!
<re_irc>
<Julia> no wait it still doesn't work after an arbitrary line number >->
<re_irc>
<Julia> * >- >
<re_irc>
<Julia> false sense of security achieved
<re_irc>
< (@therealprof:matrix.org)> : Does it? Without optimisation you will have a ton of noise because even the most trivial functions will compile to dedicated code and gazillions of calls. Also it will be so slow that a lot of things won't even work.
<re_irc>
< (@jamesmunns:beeper.com)> I can't give a more satisfying answer than "it depends". you're right, it will be more verbose, but tends to "track" better. even at opt-level=1, I get a ton of "optimized out" that makes following things next to impossible without looking at the asm
<re_irc>
<Julia> changing to "opt-level = 0" let's me set the breakpoints now
<re_irc>
<rjmp> : I think 's' will inline things, which blows away most line number to instruction mapping
<re_irc>
< (@therealprof:matrix.org)> rjmp: Indeed it will. Debug symbols could reflect that though. No really sure how great that is working in real life. Same as Ryan and James I'm not really a debugger user, and if I have to use one then certainly not gdb but lldb...
<re_irc>
<Julia> just a 5-6x bigger binary to use gdb lol
<re_irc>
< (@ryan-summers:matrix.org)> From my experience as well, any usable GDB experience comes with opt-level=0. The size always blows up
<re_irc>
< (@ryan-summers:matrix.org)> Rust relies a lot on compiler optimization
<re_irc>
< (@ryan-summers:matrix.org)> Which is unfortunate, hence James' recommendation about enabling opt for dependencies, but not your main code, since that lowers the flash requirements
<re_irc>
< (@jamesmunns:beeper.com)> does anyone here actually use lldb on embedded? I've never used it because it doesn't support "load", but maybe that's not so big a deal if cargo-embed handles flashing?
<re_irc>
< (@k900:0upti.me)> It works with the openocd gdb stub
<re_irc>
< (@therealprof:matrix.org)> Yeah, never really used load. Not a problem for a regular debugger, only for the BMP where you'd have to use it.
<re_irc>
< (@yatekii:matrix.org)> : I used it before but it's kinda hit or miss :) I basically use it when gdb fails to do :)
<re_irc>
< (@k900:0upti.me)> I haven't actually used it with cargo-embed
<re_irc>
< (@k900:0upti.me)> But you can totally use it with openocd
<re_irc>
< (@jamesmunns:beeper.com)> (oh sorry, my link above was wrong, build-deps are for things like "build.rs" scripts and proc macros, "[profile.dev.package."*"]" is what you would use for deps)
<re_irc>
would optimize all crates that are not in your current workspace/application
<re_irc>
<Julia> Okay it's slightly better, but still 3 times bigger than an optimized binary :P.
<re_irc>
< (@k900:0upti.me)> That is pretty normal
<re_irc>
<Julia> At least this will let me debug a little bit with gdb, which is cool 😄. Hopefully better support will be there eventually.
<re_irc>
< (@k900:0upti.me)> Debug info is heavy and a lot less of it survives in optimized builds
<re_irc>
< (@jamesmunns:beeper.com)> (fwiw, debug info doesn't get flashed, but it seems like most of rust's optimizing options chew up the debug info)
<re_irc>
< (@jamesmunns:beeper.com)> not sure what you meant by "heavy" k900, sorry if I misunderstood.
<re_irc>
< (@k900:0upti.me)> I mean the disk size
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, I think Julia should be measuring the actual target flash size (with the "size" binutil), we talked about that previously.
<re_irc>
<Julia> Now to make it shutup, -q apparently doesn't do that.
<re_irc>
< (@therealprof:matrix.org)> Speaking of OpenOCD... They seem to be keeping their new release cycle pace (every year rather than decade). They've released 0.12.0 two days ago...
<re_irc>
< (@anand21:matrix.org)> : Hi , Do we have a working example of this setup of using a startup code and all?
emerent has quit [Ping timeout: 260 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
<re_irc>
<Julia> Has anyone here worked with freertos-rs? Or would you recommend against it and tell me to use rtic instead?
<re_irc>
< (@k900:0upti.me)> Generally it'll be easier to use a pure Rust tool like RTIC or Embassy
<re_irc>
< (@k900:0upti.me)> So unless FreeRTOS does something specific that you need and no Rust library does, I wouldn't recommend it
<re_irc>
<Julia> What is a good place to get started with RTIC? Some examples might be nice, just a simple blinky using a periodic task for instance.
<re_irc>
< (@k900:0upti.me)> https://rtic.rs has an entire book
<re_irc>
<Julia> Awesome, I'll give that a look first :D!
<re_irc>
<Julia> Quick question, are higher priorities denoted by higher numbers with RTIC?
<re_irc>
<Julia> The course I follow on real-time systems does it exactly opposite if that's the case 😅.
<re_irc>
< (@adamgreig:matrix.org)> In cortex m hardware, smaller numbers have higher priority, but rtic instead has higher numbers for higher priority
<re_irc>
< (@firefrommoonlight:matrix.org)> : Yea this is confusing if you're new and switching between teh 2
<re_irc>
<dngrs (spookyvision@{github,cohost})> we need enums everywhere
<re_irc>
<dngrs (spookyvision@{github,cohost})> though, if you have more than a few priority levels, names would get weird I suppose
<re_irc>
<dngrs (spookyvision@{github,cohost})> might go all in and use UUIDs
<re_irc>
"IRQ_PRIO_0x0FAD_B2D7_... // see reference manual for actual priority"
<re_irc>
< (@jannic:matrix.org)> That still assumes that there is a predefined mapping between these values and actual priorities. Much too inflexible. Can't we make that configurable?
<re_irc>
< (@dkhayes117:matrix.org)> : GD32V was the same way I believe.
<re_irc>
< (@therealprof:matrix.org)> : Similar but WCH seems to have taken the copying to a new level, GD32V took mostly the peripherals blocks, but they seem to have taken everything, including ARM concepts like NVIC, SysTick and STM32 Pin names, part numbering schemes, clocking, HAL APIs and whatnot.