-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement static linking #64
Conversation
This seems like a good step forwards making trait objects work! I verified this testing the format! macro which works as expected. Unfortunately, the blink program does not work (see my other comment). |
I don't see this comment -- would you mind pointing it out to me? |
It's in the review but you should be able to see it in the conversation overview as well. |
e2c112c
to
7d44cd6
Compare
Thank you for the PR regarding this problem which is open for a long time now.
In total this would amount to some kind of dynamic choice of linker script. |
Right now, layout.ld is ARM-specific but not specific to any chip or board. It requires some per-chip and per-application definitions (TEXT, SRAM, and MPU_MIN_ALIGN) to be given by the application linker script. This means that applications will need to provide their own linker script (whereas previously they could use libtock-rs's directly). An example is provided at the top of layout.ld. Different applications can have linker scripts that place them into different locations. There isn't a clean way to calculate where applications located after the first application will be, unfortunately, but it should be possible to provide that up front (yes, I admit this is somewhat hacky). I don't see where anything I did precludes applications from using their own linker scripts to handle exactly these issues. Am I missing something? That said, I don't have either an nRF52 or a hail to test on; any testing you can provide would be appreciated. |
7d44cd6
to
9ead86b
Compare
This PR is blocked until the next release of elf2tab to crates.io. |
This PR depends (at least formally) on #63 which is possibly going to be reverted because it breaks most of the examples. |
This should do all necessary initialization except for dynamic relocations. We do not perform dynamic relocations yet because it's unclear what they will look like for ROPI-RWPI.
We have integration tests (which you can run via ./run_hardware_tests.sh) which allow us to see regression in core functionality more easily. They currently need IPC, which will be impossible after we merge the pull request. We should amend the tests, so we can have some half-manual tests to find regression in pull requests. Moreover, we should remove the IPC driver as well as the IPC examples, as they will be broken for now. |
Proper compiler support for ROPI-RWPI relocation is a ways off; in the meantime, this lets Rust apps work on Tock. The application will need to know where it will be loaded in RAM, which requires adjusting the kernel's linker script. To support the existing examples, I guessed where an application would be loaded on the nRF52-DK. An application also needs to know where its .text will end up, which is immediately after the protected region. To make this predictable, we need to fix the protected region size. This is done using elf2tab's --protected-region-size, added in tock/elf2tab#6. Users of libtock-rs will need a recent elf2tab and must pass an appropriate value for protected-region-size to elf2tab.
9ead86b
to
63bdba1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've gone over this PR with @jrvanwhy and am in favor of merging it. It means we'll finally have correct Rust support, albeit with the limitation that it only supports a single process. It looks like we've solved the issue that @Woyten pointed out -- nice catch! -- so this can move forward. We're just waiting for @bradjc to release the new elf2tab.
IPC removal is in #69 |
I pulled the IPC client removal/cleanup into its own PR (#69). I think the layout file include improvement belongs in a separate PR. I believe the only remaining blocking issue is an elf2tab release. |
The static linking setup depends on a feature introduced in 0.4.0.
elf2tab version 0.4.0 was just released with the necessary changes. I've added a commit updating the README's elf2tab installation instructions. |
Because ROPI-RWPI support in the compiler is incomplete, this changes the libtock-rs layout file to allow Rust apps to be statically-linked. With this change in place, all language features should work correctly.
The caveat is we lose the ability to dynamically load Tock applications and we need to predict the size of the TBF headers in the application image. When compiler support for ROPI-RWPI is complete I'll implement any necessary dynamic relocation steps and reverse this change.
This change depends on Initialize .data and .bss in libtock-rs. and Implement a --protected-region-size... in elf2tab.