<zaven[m]>
hey team, sometimes my variables section shows the follow value for all variable when I am debugging in VSCode. Can someone here explain what is going ?
<zaven[m]>
< Unimplemented: Attribute Value for DW_AT_type DebugInfoRef(DebugInfoOffset(413426)) >
<zaven[m]>
* hey team, sometimes my variables section shows the follow value for all variable when I am debugging in VSCode. Is someone here able to explain what is going on? This makes the debugger much less useful.
<zaven[m]>
\< Unimplemented: Attribute Value for DW\_AT\_type DebugInfoRef(DebugInfoOffset(413426)) >
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
<zaven[m]>
<zaven[m]> "hey team, sometimes my variables..." <- yeah any actual value is not being printed out. the object hierarchy is there, but the value is always this same 'Unimplemented' message
<zaven[m]>
<zaven[m]> "yeah any actual value is not..." <- fixed w/
<zaven[m]>
lto = false # link-time optimizations
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
I also found it useful for making drivers for one-off peripherals (like a PL011 UART) that appear in many different chips at many different addresses.
<thejpster[m]>
I've mdae two already this week (although dang-nabbit, my chip is still faulting when I talk to peripherals, even the peripheral I thought I needed to use to turn stuff on so the other stuff would stop faulting)
<JamesMunns[m]>
Looks good! Any reason you stuck with `&mut self` for everything vs `&self`?
<JamesMunns[m]>
Also do you limit all the fields to be specific (integer?) types? I know someone mentioned that using a field as bool and reading a value other than 0/1 would be UB, and using volatile ops on values larger than the atomic load width would probably be sus
<MathiasKoch[m]>
ahhh.. thank you! seems so fucking obvious!
<MathiasKoch[m]>
Now all my tests pass again. Thanks!
<dirbaio[m]>
also you can remove the ref mut
<MathiasKoch[m]>
👍️
<thejpster[m]>
James Munns: I added a padding check and RO field support. I don't love the proc-macro code, but it works well enough for the user.
<JamesMunns[m]>
I just wanted to capture my initial thoughts, no need to prioritize anything on my behalf :)
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Not loving the proc-macro code is common occurance :P
<diondokter[m]>
s/occurance/occurrence/
bogdan[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
why is there both proc_macro and proc_macro2? Why is it so messy trying to get a list of attributes?
<dirbaio[m]>
proc_macro can only be used from actual proc macro crates
<dirbaio[m]>
proc_macro2 is a copy of it that you can use from regular Rust code, for example you need it if you want to write tests that use it
<dirbaio[m]>
yes, it sucks
<thejpster[m]>
Ok, so that’s why quote! returns a proc_macro2::TokenStream?
<dirbaio[m]>
yep
<thejpster[m]>
I mean it’s not that bad. It only took a couple of hours to write my first derive macro. I’m just out of my depth, and I didn’t find any good guides on the subject.
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
There is still the OG proc macro workshop from dtolnay https://github.com/dtolnay/proc-macro-workshop though not sure from memory if he goes into proc_macro vs proc_macro2
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
Just want to remind you of the topic. Nothing has happened in the last weeks.
balbi[m] has joined #rust-embedded
<balbi[m]>
is it possible to have svd2rust generate 8-bit, 16-bit, and 32-bit accessors for the register address? My HW behaves differently given the write size.