<Jubilee[m]>
<dirbaio[m]> "The weirdest by far is probably..." <- Oh, I specifically mean the cases where they're marking segments of a binary by a "start" `static` and an "end" `static`, not the case that defmt uses.
<dirbaio[m]>
Hmm the only ones I can think of then is the ones in Cortex-m-rt crate, but those are fairly standard. Other -rt crates for other archs do similarly
<Jubilee[m]>
dirbaio[m]: I guess I'll settle for "fairly standard" then! I mostly want to see the complications of how these hijinx actually get used.
<dirbaio[m]>
in this case they're used by asm, not a Rust static, because it was believed it'd be UB to use Rust to initialize the statics
<dirbaio[m]>
this one does use them from rust. it's used to allocate a chunk of memory to do IPC with a modem (another core running vendor-provided firmware). it's allocated via linker script like that because the address has to be aligned because the memory has to be aligned to 8kb
<Jubilee[m]>
So, I'm actually doing research to get the idea of who I need to talk to in order to make sure to bring their concerns to T-lang and T-opsem, to understand what decisions need to be made here, because we would like it to be as easy as possible for these cases to be engaged in. One of the rules of Rust is that a static can never overlap with another static, and the other is that if T: Freeze... AKA "an immutable without
<Jubilee[m]>
internal UnsafeCell"... then it must be initialized the very moment that Rust sees it.
<Jubilee[m]>
I think the prohibition re: init is actually stronger than what I'm saying, I'm still paging in some memory here.
<Jubilee[m]>
IIRC the rule for the former gets weakened if the static is extern "C" { static }.
<dirbaio[m]>
yeah, hence the use of asm :D
<dirbaio[m]>
a long while ago cortex-m-rt used rusrt, it was changed to asm out of fear it was UB. afaik no one saw any miscompilations though
<dirbaio[m]>
also related, i'm pretty sure the 2nd example I linked (the nrf91 one) violates provenance because it's taking a pointer to what the compiler thinks is a u8 and making a bigger slice
<Jubilee[m]>
that only violates stacked borrows
<dirbaio[m]>
it seems impossible to use these "marker statics" soundly from rust currently
<dirbaio[m]>
so everyone just writes possibly-unsound code and prays it works
<Jubilee[m]>
yes, I would like to put an end to that.
<dirbaio[m]>
that would be lovely :D
<dirbaio[m]>
Jubilee[m]: yes
<Jubilee[m]>
...in the sense of making at least some equivalent pattern of code sound for using from Rust, I mean, not banning it all, though it might come with yeeting one or two code patterns that are in-use.
<Jubilee[m]>
but having a blessed pattern of any shape seems most important.
<Jubilee[m]>
dirbaio[m]: my understanding is this code would not violate stacked borrows if it used `&raw mut`.
<Jubilee[m]>
Jubilee[m]: to be clear, it would still be in a somewhat ambiguous territory in terms of provenance.
<Jubilee[m]>
Jubilee[m]: but that's the case for basically all of these, so
<dirbaio[m]>
Jubilee[m]: Hmm isn't it out of bounds access anyway? The pointer is derived from the u8 "allocation" so you can't use it to write outside of it.
<Jubilee[m]>
dirbaio[m]: yes but by formulating the `&T`, in the stacked borrows model you contract the possible range of the allocation you are entitled to read or write to exactly that range, whereas formulating a pointer does not do this.
<Jubilee[m]>
Jubilee[m]: expressing that there really is an "allocation" there is still hard to do.
<Jubilee[m]>
Jubilee[m]: I think of all that stuff it's the `offset_from` that might be actually clearly UB lmao.
<Jubilee[m]>
Jubilee[m]: dirbaio: To be clear, the problem you are referring to... the "pointer to Header" pattern... is something we *have* to solve in Rust in *some* way, we can't just shrug it off, and we've discussed it extensively at https://github.com/rust-lang/unsafe-code-guidelines/issues/256
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
ooh, thiserror 2.0 released with no_std support
anon143 has quit [Ping timeout: 252 seconds]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
PhilMarkgraf[m] has joined #rust-embedded
<PhilMarkgraf[m]>
Does anyone have a good reference on how to find/generate (and possibly interpret) the memory map of the embedded application. I presume all the data is there in the ELF file, but I've not found how to get at the information. (I think in my C++ days, we had the linker set up to always dump a map file.)
<PhilMarkgraf[m]>
P.S. Do folks modify the build operations to routinely generate a map file?
AdamHorden has quit [Quit: Adam Horden | adam.horden.me]
AdamHorden has joined #rust-embedded
<Darius>
you can run objdump over the resulting elf file
<Darius>
eg objdump -S foo.elf >foo.dmp
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
Has anyone here done anything relating to BLE audio in Rust or is that going to be misery to go through
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
<M9names[m]>
<PhilMarkgraf[m]> "Does anyone have a good referenc..." <- > <@shakencodes:matrix.org> Does anyone have a good reference on how to find/generate (and possibly interpret) the memory map of the embedded application. I presume all the data is there in the ELF file, but I've not found how to get at the information. (I think in my C++ days, we had the linker set up to always dump a map file.)
<M9names[m]>
> P.S. Do folks modify the build operations to routinely generate a map file?
<M9names[m]>
I frequently use nm to interrogate memory usage. Usually with print-size and sorting by size, since the large objects are usually what I care about most
<Darius>
PhilMarkgraf[m]: not sure you got my previous message but you can run objdump -S foo.elf >foo.dmp
<Darius>
or maybe the bridge is toast..
<M9names[m]>
Darius: Bridge is fine. Maybe you're misinterpreting my reply?
<Darius>
could be :)
<Darius>
yeah sorry, the way replies get mangled had me confused
<M9names[m]>
Yeah. Kinda hard to preserve that info in an easy to read way across protocols
<Darius>
yeah
wose has quit [Ping timeout: 260 seconds]
wose has joined #rust-embedded
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
Brons[m] has quit [Quit: Idle timeout reached: 172800s]
anton_star has joined #rust-embedded
<berkus[m]>
<adamgreig[m]> "ooh, thiserror 2.0 released with..." <- Time to drop Snafu?
anton_star has quit [Quit: Client closed]
sroemer has quit [Ping timeout: 272 seconds]
anton_star has joined #rust-embedded
<thejpster[m]>
Oooh, imagine if it had defmt support.
<thejpster[m]>
<PhilMarkgraf[m]> "Does anyone have a good referenc..." <- > <@shakencodes:matrix.org> Does anyone have a good reference on how to find/generate (and possibly interpret) the memory map of the embedded application. I presume all the data is there in the ELF file, but I've not found how to get at the information. (I think in my C++ days, we had the linker set up to always dump a map file.)
<thejpster[m]>
> P.S. Do folks modify the build operations to routinely generate a map file?
<thejpster[m]>
Rust doesn’t have good tools for doing post-build steps. cargo-binutils includes tools like cargo objdump which will do a build and then call objdump on it. And -t gets objdump to dump a symbol table. Or you could pass some rustflags in .cargo/config.toml and get the linker to dump a map file. It’s the same linker after all.
sroemer has joined #rust-embedded
<JamesMunns[m]>
<PhilMarkgraf[m]> "Does anyone have a good referenc..." <- > <@shakencodes:matrix.org> Does anyone have a good reference on how to find/generate (and possibly interpret) the memory map of the embedded application. I presume all the data is there in the ELF file, but I've not found how to get at the information. (I think in my C++ days, we had the linker set up to always dump a map file.)
<JamesMunns[m]>
> P.S. Do folks modify the build operations to routinely generate a map file?
<JamesMunns[m]>
If you JUST want symbols, you might want `nm` more than `objdump`. You can run `cargo nm --release -- -nS` to get the dump of all symbols and their addrs, "scatter file" style.
<JamesMunns[m]>
JamesMunns[m]: (the columns are addr, size, kind, name)
demolemon[m] has quit [Quit: Idle timeout reached: 172800s]
korken89[m] has joined #rust-embedded
<korken89[m]>
Hey thejpster I say that I have an private convo request, but I'm unable to join. Did you maybe cancel it or is Matrix acting up? :)
<korken89[m]>
s/say/saw/
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
wassasin[m] has joined #rust-embedded
<wassasin[m]>
korken89[m]: I have had a similar problem recently with private convo's
<korken89[m]>
Ah, that'
<korken89[m]>
* Ah, that's unfortunate
anton_star has quit [Quit: Client closed]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
<thejpster[m]>
Yeah my bad. Sorry.
barafael[m] has joined #rust-embedded
<barafael[m]>
What are y'all using to access GPS from MCUs? I have a neo-8m module. But I'm open to get another one if it's better supported. Most of the crates I found do not support no_std etc.
davidmpye[m] has joined #rust-embedded
<davidmpye[m]>
Is there an easy way to see when you compile/upload (Pico in my case) how much of the flash etc your project is using?
<davidmpye[m]>
I want to know how many more features I can jam in
<barafael[m]>
<Ralph[m]> "> <@rursprung:matrix.org> does..." <- I just ordered some. Todd Stellannova has a driver. I pr'd early embedded hal 1 support today
<Ralph[m]>
<barafael[m]> "I just ordered some. Todd..." <- thanks for the feedback! did you order an FSM300 or something else based on the BNU08X? do you have a link for this driver / your PR?
<Ralph[m]>
* thanks for the feedback! did you order an FSM300 or something else based on the BNU08X? ~do you have a link for this driver / your PR?~
<Ralph[m]>
* thanks for the feedback! did you order an FSM300 or something else based on the BNU08X? <del>do you have a link for this driver / your PR?</del>