Skip to content
This repository has been archived by the owner on Jun 19, 2024. It is now read-only.

Hot/Cold Linking #104

Open
Tropix126 opened this issue Mar 9, 2024 · 0 comments
Open

Hot/Cold Linking #104

Tropix126 opened this issue Mar 9, 2024 · 0 comments
Labels
help wanted Extra attention is needed scope:bindings Modifies pros-sys bindings scope:platform_support Updates Rust support (e.g. panic handler, allocator, etc) type:enhancement New feature or request

Comments

@Tropix126
Copy link
Member

Tropix126 commented Mar 9, 2024

What's the motivation for this feature?

This has been discussed for a bajillion years, so we might as well open an issue for it now.

Describe the solution you'd like

Hot/Cold linking is a strategy used by PROS C++ projects to split libraries and user functions into two separate binaries in order to save on upload times. Libraries are uploaded once (or whenever they're changed) as the larger cold image, while user functions are uploaded in the hot image. These are then linked together both at compile time through some linker tricks and at runtime using VEX's serial file protocol, which allows linking together bins at runtime through memory offsets. I'll spare the rest of the details, since a significant amount of RE has already gone into this, but it's for sure something we want to support.

Describe the drawbacks, if any

It isn't entirely clear how this will play into Rust's tooling. Everything is linked statically into a monlith binary currently, which makes things a little difficult. Rust having an unstable ABI certainly doesn't help the case, making it difficult to split individual crates across binaries. Nevertheless, it's likely possible to at least throw libpros into a cold package. It might be possible to do some linker magic and binary splitting through objcopy to somehow get the binaries to be fully split without pissing off the linker.

Key takeaway is that the main thing preventing support for this right now is a lack of understanding of how this will fit into Rust/Cargo's tooling/build paradigm.

Describe the alternative solutions, if any

Keeping a monolith is always an option, but that'd be admitting defeat.

Additional context

Plenty of reading out there (along with all of the discord discussions):
https://gist.github.com/Tropix126/bf90b92379c78060ec9039f9013d80db
https://github.com/LemLib/v5-serial-protocol/blob/d927082078e1043b393e7b4dfaaab9f6c3d47bb8/src/VexConnection.ts#L404
https://github.com/purduesigbots/pros/blob/develop/src/system/hot.c
https://pros.cs.purdue.edu/v5/tutorials/topical/wireless-upload.html#:~:text=Building%20with%20hot%2Fcold%20linking,different%20cold%20package%20is%20uploaded
https://internals.pros.rs/hard-to-implement/hot-cold
https://www.robotmesh.com/studio/content/jsx/robotmesh/tsjs/interfaces/vexv5_download.js
https://github.com/purduesigbots/pros/blob/develop/firmware/v5-hot.ld
https://github.com/purduesigbots/pros/blob/develop/common.mk
purduesigbots/pros#89

@Tropix126 Tropix126 added type:enhancement New feature or request help wanted Extra attention is needed scope:bindings Modifies pros-sys bindings scope:platform_support Updates Rust support (e.g. panic handler, allocator, etc) labels Mar 9, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
help wanted Extra attention is needed scope:bindings Modifies pros-sys bindings scope:platform_support Updates Rust support (e.g. panic handler, allocator, etc) type:enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant