#tock

/

      • kickliter
        The why of this is that I'm trying to get rid of the `+ 40` here: https://gist.github.com/JayKickliter/2466e9d2e1...
      • bradjc[m]
        I believe `Process.text` points to the start of the flash region for the process.
      • kickliter
        Maybe it needs a different name?
      • bradjc[m]
        Where the .text from the process’s linker script ends up varies both based on how the app is compiled and where the kernel/tockloader decides to put it. But the start of the app binary will be after the protected region (basically the address that `flash_non_protected_start()` returns).
      • And yes, Process.text should be renamed
      • brghena[m]1
        When we create an LST file, we offset it by the location of the init function, which is probably what you want: https://github.com/tock/tock/blob/master/kernel...
      • kickliter
        I'm still not sure if it's coincidence that the +40 offset that I need to to add to the result of `flash_non_protected_start()` is the same as the size of `struct hdr`?
      • brghena[m]1
        Presumably the math you have to do is this same math: https://github.com/tock/tock/blob/master/kernel...
      • kickliter
        brghena[m]: I think it is, but `_init` is in a different section, so I'm not 100% sure. I'm just trying to figure out what's needed to make userland debugging easier
      • brghena[m]1
        Yeah, it's unfortunately always been a little complicated
      • bradjc[m]
        i think it is coincidence. the first thing after the protected region is the crt0 header, which happens to be 10 32 bit values https://github.com/tock/libtock-c/blob/master/u...
      • .app_state is next, so if you use the app_state library that would take up space, and then .text
      • brghena[m]1
        Uhh, by definition doesn't the comment say that it is the size of `struct hdr`?
      • kickliter
        what I put in that gist works pretty well, and is the simplest solution I've come up with so far.
      • bradjc[m]
        ah yes if that is what struct hdr is
      • of course
      • but its still sorta coincidence because an app could use a different linker file and could use the app_state library
      • brghena[m]1
        Yup
      • And using app_state will offset that by more, for sure
      • jsgf has quit
      • So, if you never use app_state, and don't do any linker changes of your own, that +40 will work until we change something
      • The "better" way is to read out fields and walk it like http://process.rs does, which will be robust, although that will take longer and be more complicated
      • kickliter
        brghena[m]1 : that's what I used to do in GDB. It was a few hundred lines of the ugliest GDB script you've ever seen
      • brghena[m]1
        : )
      • kickliter
        Ok. It looks what I want is missing, but doable (since the kernel needs to know this info). I think everything I need is already there just not made `pub`lic
      • made
      • so many typos
      • brghena[m]1
        You're looking for the kernel to print out a different number on fault?
      • Shouldn't GDB be able to take an LD file into account in some way? (Note: I'm not good at GDB)
      • kickliter
        WHat I'm doing in that gist setting a GDB beakpoint on `load_process_hook()`, which is defined in my board's main.rs. GDB breaks on that and uses the arguments `name` and `text_addr` to find the correct `elf` file to load for symbols and set the correct offset
      • brghena[m]1
        That's super cool
      • kickliter
      • jsgf joined the channel
      • eupn joined the channel
      • eupn has quit
      • jsgf has quit
      • jsgf joined the channel
      • eupn joined the channel
      • eupn has quit
      • jsgf has quit
      • eupn joined the channel
      • eupn has quit
      • eupn joined the channel
      • eupn has quit
      • eupn joined the channel
      • eupn has quit
      • eupn joined the channel
      • timocin joined the channel
      • timocin
        Hi guys! I am looking into developing futures for tock. The more i research the harder it seems to get as tock operates in a no std environment. I found out that the only crate that supports no_std is futures 0.1.20. I have two options. 1) Trying to implement futures using the version mentioned previously 2) Look deeper into the concept of futures
      • and replicate these with the mechanisms i have available on Tock.
      • My question is. Which one of these sounds more reasonable to work with in a short time frame?
      • alevy
        how short?
      • timocin
        1 month
      • alevy
        I'd try just prototyping something using the futures trait
      • are you saying futures > 0.1.20 is not no_std? or that after 0.1.20 all versions should be no_std?
      • timocin
        Alright. Yes from what i have understood 0.1.20 is the only one that supports no_std.
      • alevy
        timocin: only one as in no other version _every_ will, or only one as in it is the _first_ version that will
      • yeah it looks like all versions of futures from now on will
      • tokio is a specific library using futures for doing I/O on a Unix system. it doesn't make much sense for Tock anyway, so that's fine
      • eupn
        I think it's totally possible to use futures in no-std environment without Tokio
      • timocin
        Yeah. That was a misunderstanding of mine that made me post that question. Since tokio uses librarys from mio which is using std will not work ehre
      • alevy
        yes, Futures is _just_ a set of traits
      • eupn
        Since futures crate is just a bunch of traits
      • alevy
        timocin: i would take a very stripped down version of Tock---perhaps nRF52-dk with most of the drivers taken out (perhaps even without any of the system call drivers at first), but with at least one asynchronous capsule, such as the UART/Console, and try and port that to somehow use futures instead of a state machine
      • eupn
        The thing is to implement futures reactor/executor under Tock
      • alevy
        for a first stab, my bet is you'll have to change a fair bit of code throughout. and the things to look for are: (a) whether having `&mut` references can be avoided in futures, (b) whether you find you need to dynamically allocate stuff that's not otherwise dynamically allocated (c) whether it's difficult to make operations non-blocking
      • my guess that in 1 month it might be too ambitious to try and implement something general purpose, but you can probably at least come out with some insights on what would be required to do so (can it be done using existing Tock interfaces, if not what would need to be changed, are there performance/memory costs, etc)
      • timocin
        Sounds good, i will start stripping down the nRF52-dk and start working on the things you mentioned. I will come back with more questions on the go. Thank you guys for the help.
      • alevy
        👍