Skip to content
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

Merged
merged 2 commits into from
Feb 7, 2019
Merged

Implement static linking #64

merged 2 commits into from
Feb 7, 2019

Conversation

jrvanwhy
Copy link
Collaborator

@jrvanwhy jrvanwhy commented Jan 29, 2019

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.

@Woyten
Copy link
Contributor

Woyten commented Jan 30, 2019

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).

@jrvanwhy
Copy link
Collaborator Author

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?

@Woyten
Copy link
Contributor

Woyten commented Jan 30, 2019

It's in the review but you should be able to see it in the conversation overview as well.

nrf52_layout.ld Outdated Show resolved Hide resolved
@jrvanwhy jrvanwhy force-pushed the static-linking branch 2 times, most recently from e2c112c to 7d44cd6 Compare January 31, 2019 02:32
@torfmaster
Copy link
Collaborator

Thank you for the PR regarding this problem which is open for a long time now.
There are two things which I'l like to keep in mind (inside this pull request, inside another).

  • libtock-rs works on other boards as well (e.g. hail). We should propably allow for the user of the library to choose a target platform
  • currently, we have some applications (as the hardware tests and ipc-examples) which allow using two apps installed in parallel. It would be nice (also from a perspective of automated testing) to make this possible using the new approach.

In total this would amount to some kind of dynamic choice of linker script.

@jrvanwhy
Copy link
Collaborator Author

Thank you for the PR regarding this problem which is open for a long time now.
There are two things which I'l like to keep in mind (inside this pull request, inside another).

  • libtock-rs works on other boards as well (e.g. hail). We should propably allow for the user of the library to choose a target platform
  • currently, we have some applications (as the hardware tests and ipc-examples) which allow using two apps installed in parallel. It would be nice (also from a perspective of automated testing) to make this possible using the new approach.

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.

@torfmaster
Copy link
Collaborator

This PR is blocked until the next release of elf2tab to crates.io.

@torfmaster
Copy link
Collaborator

This PR depends (at least formally) on #63 which is possibly going to be reverted because it breaks most of the examples.

jrvanwhy referenced this pull request Feb 2, 2019
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.
@torfmaster
Copy link
Collaborator

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.
Copy link
Collaborator

@phil-levis-google phil-levis-google left a 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.

@jrvanwhy
Copy link
Collaborator Author

jrvanwhy commented Feb 6, 2019

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.

IPC removal is in #69

@jrvanwhy
Copy link
Collaborator Author

jrvanwhy commented Feb 6, 2019

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.
@jrvanwhy
Copy link
Collaborator Author

jrvanwhy commented Feb 6, 2019

elf2tab version 0.4.0 was just released with the necessary changes. I've added a commit updating the README's elf2tab installation instructions.

@jrvanwhy jrvanwhy removed the blocked label Feb 6, 2019
@jrvanwhy jrvanwhy merged commit 1eba2c1 into tock:master Feb 7, 2019
@jrvanwhy jrvanwhy deleted the static-linking branch February 7, 2019 22:51
@jrvanwhy jrvanwhy mentioned this pull request Feb 8, 2019
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants