knurling-rs / flip-link Goto Github PK
View Code? Open in Web Editor NEWAdds zero-cost stack overflow protection to your embedded programs
License: Apache License 2.0
Adds zero-cost stack overflow protection to your embedded programs
License: Apache License 2.0
given this line in the MEMORY
command:
RAM : ORIGIN = 0x20020000, LENGTH = 2K - 1K
flip-link
internally computes the length as 2048
instead of as 1024
step check fmt
just failed with:
Run rustup component add rustfmt
11
error: component 'rustfmt' for target 'x86_64-unknown-linux-gnu' is unavailable for download for channel nightly
12
Sometimes not all components are available in any given nightly.
13
Error: Process completed with exit code 1.
see https://github.com/knurling-rs/flip-link/runs/1306337612?check_suite_focus=true
A layout like this:
memory.x:
INCLUDE common.ld
MEMORY
{
FLASH : org = 0x08004400, len = 319k
}
common.x:
MEMORY
{
FIRMWARE : org = 0x08004000, len = 320k
FWUPDATE : org = 0x08054000, len = 320k
FWSWAP : org = 0x080A4000, len = 320k
RAM : org = 0x20000000, len = 96k /* SRAM1 */
RAM2 : org = 0x10000000, len = 32K /* SRAM2 */
}
Does not work with the current "naive" line-by-line parser.
CI compiles the test-flip-link-app
(binary) crate to the ARM Cortex-M architecture as an 'it links' test.
We should extend this test and also check that the memory layout of the output ELF is indeed "flipped".
Steps:
object
crate to parse the output ELF.vector_table
linker section and extract the initial SP pointer
valuestatic RAM
(the .bss
, .data
and .uninit
linker sections)initial SP pointer
(2) should be lower/smaller than the lowest boundary of static RAM
These steps could be done in a test file in the root (e.g. test/verify.rs
): the test function would build the test-app and then verify its memory layout.
This cargo test
will run the unit tests in src/main.rs
as well as this new test.
cargo-generate
, just clone the app repo and apply a patch that makes the changes generate
would make (saves compile time)app-template
windows os: 11
I use https://github.com/knurling-rs/app-template
generate project
add
cortex-m-rtic = { version = "1.1.3" }
error: linking with `flip-link` failed: exit code: 1
|
= note: "flip-link" "-flavor" "gnu" "C:\\Users\\zhaobo\\AppData\\Local\\Temp\\rustck3K05Z\\symbols.o" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\main-11049d013bb1904c.main.2fc7ea03-cgu.0.rcgu.o" "--as-needed" "-L" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps" "-L" "D:\\projects\\embeed\\app\\target\\debug\\deps" "-L" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\build\\cortex-m-5817308009678109\\out" "-L" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\build\\cortex-m-rt-4199a1caeb388d95\\out" "-L" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\build\\defmt-d86b0063a8a3b56a\\out" "-L" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\build\\stm32f1-14b8b2830e44275e\\out" "-L" "D:\\software\\rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\thumbv7m-none-eabi\\lib" "-Bstatic" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libstm32f1xx_hal-8051c863c3ad98b5.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libfugit_timer-fe7d59127748e96a.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libbxcan-e9e7ad35b16a23e4.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libstm32_usbd-ed785f6b86adbff3.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libusb_device-a233a87681d50602.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libfugit-6c4bc25732b1db27.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libgcd-4197544a75179d12.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libembedded_dma-d8fa02c1119216ed.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libstm32f1-b31ddd66260981cf.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libcortex_m_rt-c1a6a9ab4f0cfe1e.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\librtic-34882a4391d40282.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libheapless-3a2e6cf7174401b1.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libstable_deref_trait-b94e8061351ccd46.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libhash32-2ef9212d208b60d7.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libbyteorder-90345a976a4d83d8.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libbare_metal-7b4e9559ea5371a8.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\librtic_monotonic-8232f0df63c185a6.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\librtic_core-fbd27b968ff823cf.rlib" "--start-group" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libpanic_probe-a9b08e11c9fb609a.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libdefmt-d4cf8a2ca51cf9ce.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libbitflags-5351597746fc1950.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libcortex_m-f44fc0a28245896b.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libembedded_hal-0f940bf2e1d93e1f.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libvoid-b7e1daec3a29df70.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libnb-9a0f1077e9087fcc.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libnb-89e12803df9a6252.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libvolatile_register-1ef2fbeaac4c48e3.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libvcell-894f713cc598d2e9.rlib" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\libbare_metal-392c59e661be3df0.rlib" "D:\\software\\rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\thumbv7m-none-eabi\\lib\\librustc_std_workspace_core-d708ca894357bb88.rlib" "D:\\software\\rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\thumbv7m-none-eabi\\lib\\libcore-7279b5ba9f24caff.rlib" "--end-group" "D:\\software\\rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\thumbv7m-none-eabi\\lib\\libcompiler_builtins-25380e8375a00138.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "D:\\software\\rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\thumbv7m-none-eabi\\lib" "-o" "D:\\projects\\embeed\\app\\target\\thumbv7m-none-eabi\\debug\\deps\\main-11049d013bb1904c" "--gc-sections" "-O1" "-Tlink.x" "-Tdefmt.x" "--nmagic"
= note: rust-lld: error: undefined symbol: _defmt_acquire
>>> referenced by mod.rs:55 (D:\software\cargo\registry\src\rsproxy.cn-8f6827c7555bfaf8\defmt-0.3.2\src\export\mod.rs:55)
>>> panic_probe-a9b08e11c9fb609a.panic_probe.02df55b0-cgu.0.rcgu.o:(rust_begin_unwind) in archive D:\projects\embeed\app\target\thumbv7m-none-eabi\debug\deps\libpanic_probe-a9b08e11c9fb609a.rlib
rust-lld: error: undefined symbol: _defmt_release
>>> referenced by mod.rs:71 (D:\software\cargo\registry\src\rsproxy.cn-8f6827c7555bfaf8\defmt-0.3.2\src\export\mod.rs:71)
>>> panic_probe-a9b08e11c9fb609a.panic_probe.02df55b0-cgu.0.rcgu.o:(rust_begin_unwind) in archive D:\projects\embeed\app\target\thumbv7m-none-eabi\debug\deps\libpanic_probe-a9b08e11c9fb609a.rlib
rust-lld: error: undefined symbol: _defmt_write
>>> referenced by mod.rs:85 (src\export\mod.rs:85)
>>> defmt-d4cf8a2ca51cf9ce.defmt.d14e61bb-cgu.0.rcgu.o:(_$LT$$RF$mut$u20$W$u20$as$u20$core..fmt..Write$GT$::write_char::hbf1e7cda46151703) in archive D:\projects\embeed\app\target\thumbv7m-none-eabi\debug\deps\libdefmt-d4cf8a2ca51cf9ce.rlib
>>> referenced by mod.rs:85 (src\export\mod.rs:85)
>>> defmt-d4cf8a2ca51cf9ce.defmt.d14e61bb-cgu.0.rcgu.o:(_$LT$$RF$mut$u20$W$u20$as$u20$core..fmt..Write$GT$::write_str::h9be493d4997977cf) in archive D:\projects\embeed\app\target\thumbv7m-none-eabi\debug\deps\libdefmt-d4cf8a2ca51cf9ce.rlib
>>> referenced by mod.rs:85 (src\export\mod.rs:85)
>>> defmt-d4cf8a2ca51cf9ce.defmt.d14e61bb-cgu.0.rcgu.o:(defmt::export::istr::hf51bfc040acfc767) in archive D:\projects\embeed\app\target\thumbv7m-none-eabi\debug\deps\libdefmt-d4cf8a2ca51cf9ce.rlib
>>> referenced 2 more times
flip-link: the native linker failed to link the program normally; please check your project configuration and linker scripts
warning: `app` (bin "main") generated 3 warnings
error: could not compile `app` due to previous error; 3 warnings emitted
I don't know exactly why this is a thing, but when the arguments passed to rust lld are too long (?) it gets passed a special argument (at the bottom of this page) that refers to a file. Currently, flip-link doesn't seem to handle this.
I've made a fork that "fixes" the bug by just hardcoding support and using a bunch of unwraps here, but I imagine someone who knows how linkers work and can make a good solution should be the one to make the PR.
Dear Knurling-rs community,
Most of us maintainers of Knurling-rs will be on vacation from this week until the beginning of January. Therefore please do not expect too much activity in our repositories and issue tracker.
We wish you a great holiday season (if you have it) or, otherwise, just a good time.
Best, your Knurling-rs team ❄️
https://github.com/axodotdev/cargo-dist will automate the process of making binaries and putting them in the release area. We could use this for flip-link, and then people can cargo binstall flip-link
and same themselves a compilation.
Currently we have various limitations of how to specify cli arguments. An out-of-the-box solution like clap
¹ would be helpful.
One limitation example is that it's only possible to pass the linker script as -Tmemory.x
, but not as -T memory.x
.
¹ - clap
in particular isn't currently easily implementable (see #29 for one approach), but would be with one of clap-rs/clap#1880, clap-rs/clap#1404.
Any plan to update flip-link for cortex-m-rt 0.7.x?
I believe it doesn't work with a hard-float target because it will work with the target set to thumbv7em-none-eabi
.
Here is my .cargo/config.toml
[target.thumbv7em-none-eabihf]
runner = "probe-run --chip STM32F334R8Tx --connect-under-reset"
rustflags = [
"-C", "linker=flip-link",
"-C", "link-arg=-Tlink.x",
"-C", "link-arg=--nmagic",
"-C", "link-arg=-Tdefmt.x",
]
[build]
target = "thumbv7em-none-eabihf"
[env]
DEFMT_LOG = "trace"
Code for reference: https://github.com/TKFRvisionOfficial/rp2040-flip-link-bug
Error
error: linking with `flip-link` failed: exit code: 1
|
= note: "flip-link" "-flavor" "gnu" "C:\\Users\\tkfrv\\AppData\\Local\\Temp\\rustcGW2dap\\symbols.o" "C:\\Users\\tkfrv\\CLionProjects\\rp2040-flip-link-bug\\target\\thumbv6m-none-eabi\\release\\deps\\rp2040_project_template-61a6aaf1e39772c5.rp2040_project_template.5e8f1fb573b13a39-cgu.0.rcgu.o" "--as-needed" "-Bstatic" "C:\\Users\\tkfrv\\AppData\\Local\\Temp\\rustcGW2dap\\libcortex_m-65d48bce61aaad5e.rlib" "C:\\Users\\tkfrv\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\thumbv6m-none-eabi\\lib\\libcompiler_builtins-4e8ba2eae5131519.rlib" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-L
" "C:\\Users\\tkfrv\\CLionProjects\\rp2040-flip-link-bug\\target\\thumbv6m-none-eabi\\release\\build\\rp2040-project-template-f8399c1cab12c2e7\\out" "-L" "C:\\Users\\tkfrv\\CLionProjects\\rp2040-flip-link-b
ug\\target\\thumbv6m-none-eabi\\release\\build\\cortex-m-613d14e986bc86ba\\out" "-L" "C:\\Users\\tkfrv\\CLionProjects\\rp2040-flip-link-bug\\target\\thumbv6m-none-eabi\\release\\build\\cortex-m-rt-0a770cf36
7971ebd\\out" "-L" "C:\\Users\\tkfrv\\CLionProjects\\rp2040-flip-link-bug\\target\\thumbv6m-none-eabi\\release\\build\\defmt-74c351c0707a4151\\out" "-L" "C:\\Users\\tkfrv\\CLionProjects\\rp2040-flip-link-bu
g\\target\\thumbv6m-none-eabi\\release\\build\\rp2040-pac-b9719b326dd91302\\out" "-o" "C:\\Users\\tkfrv\\CLionProjects\\rp2040-flip-link-bug\\target\\thumbv6m-none-eabi\\release\\deps\\rp2040_project_template-61a6aaf1e39772c5" "--gc-sections" "-O1" "--nmagic" "-Tlink.x" "-Tdefmt.x"
= note: rust-lld: error: C:\Users\tkfrv\CLionProjects\rp2040-flip-link-bug\target\thumbv6m-none-eabi\release\build\defmt-74c351c0707a4151\out\defmt.x:7: symbol not found: __defmt_default_panic␍
rust-lld: error: C:\Users\tkfrv\CLionProjects\rp2040-flip-link-bug\target\thumbv6m-none-eabi\release\build\defmt-74c351c0707a4151\out\defmt.x:7: symbol not found: __defmt_default_panic␍
rust-lld: error: C:\Users\tkfrv\CLionProjects\rp2040-flip-link-bug\target\thumbv6m-none-eabi\release\build\defmt-74c351c0707a4151\out\defmt.x:7: symbol not found: __defmt_default_panic␍
rust-lld: error: C:\Users\tkfrv\CLionProjects\rp2040-flip-link-bug\target\thumbv6m-none-eabi\release\build\defmt-74c351c0707a4151\out\defmt.x:7: symbol not found: __defmt_default_panic␍
flip-link: the native linker failed to link the program normally; please check your project configuration and linker scripts
error: could not compile `rp2040-project-template` (bin "rp2040-project-template") due to 1 previous error
If these lines get removed the application does compile:
https://github.com/TKFRvisionOfficial/rp2040-flip-link-bug/blob/848d4543624ca3558e06fda8071e8855f472a9ea/src/main.rs#L84-L87
Instantiate the app-template
for the nRF52840 (add nrf52840-hal
as a dependency).
Create a memory.x
override
$ # run hal crate build script -> puts memory.x in target
$ cargo check --lib
$ cp `fd memory.x target` .
$ # halve the amount of RAM
$ $EDIT memory.x
$ bat memory.x
MEMORY
{
FLASH : ORIGIN = 0x00000000, LENGTH = 1024K
RAM : ORIGIN = 0x20000000, LENGTH = 128K
}
$ # `touch` = force relinking; or use `cargo clean`
$ touch src/bin/hello.rs
$ cargo size --bin hello -- -A -x
hello :
section size addr
.vector_table 0x100 0x0
.text 0x145c 0x100
.rodata 0x4ac 0x155c
.data 0x30 0x2003fbc8
.bss 0x8 0x2003fbf8
.uninit 0x400 0x2003fc00
$ cargo nm --bin hello -- --demangle --numeric-sort | rg stack
2003fbc8 A _stack_start
Both binary tools indicate that flip-link
thinks the RAM size is 256 KiB (0x4_0000
) even though the memory.x
override indicates 128 KiB
rust-lld
(disable flip-link
)$ $EDIT .cargo/config.toml
$ bat .cargo/config.toml
[target.'cfg(all(target_arch = "arm", target_os = "none"))']
runner = "probe-run --chip nrf52840"
rustflags = [
# "-C", "linker=flip-link", # <- disabled
"-C", "link-arg=-Tlink.x",
"-C", "link-arg=-Tdefmt.x",
"-C", "link-arg=--nmagic",
]
$ cargo size --bin hello -- -A -x
hello :
section size addr
.vector_table 0x100 0x0
.text 0x145c 0x100
.rodata 0x4ac 0x155c
.data 0x30 0x20000000
.bss 0x8 0x20000030
.uninit 0x400 0x20000038
$ cargo nm --bin hello -- --demangle --numeric-sort | rg stack
20020000 A _stack_start
rust-lld
respects the memory.x
override and uses 128 KiB as the size of the RAM
region
flip-link
version
$ cargo install --list | rg ^flip-link
flip-link v0.1.4:
Our nightlies are failing: https://github.com/knurling-rs/flip-link/actions because our app-template patch doesn't apply anymore.This will likely break every time we update the app-template.. maybe we can come up with a less brittle way to modify the TODOs in the template?
you can base it off: https://github.com/knurling-rs/defmt/blob/main/.github/workflows/ci.yml
as a first step we should check that cargo build
works
then we should add a app-template
instance and set that up to link with flip-link
; building that project should be part of the CI
running cargo fmt
in CI would also be nice to have
publish flip-link 0.1.0 on crates.io (also tag on GitHub)
Under Support it mentions defmt
instead of flip-link
, trivial copy&paste leftover :)
This gives the same error as #3
RAM : ORIGIN = 0x20000000 + 100K, LENGTH = 256K - 100K
while this works
RAM : ORIGIN = 0x20000000, LENGTH = 256K - 100K
rust-lld
will happily link memory.x
files that contain lines like these
RAM : ORIGIN = 0x20020000, LENGTH = 1K - 2K
or even
RAM : ORIGIN = 0x20020000, LENGTH = -1K
it seems the behavior is that the value overflows because linking works even if .bss
is 1MiB in size.
we could either reject these indicating that there may be a problem in the linker script or that negative lengths are not supported.
if we want to support them then I'm not sure what flip-link
behavior should be. transforming either of the above to
RAM : ORIGIN = 0x20020000 - 1K, LENGTH = 1K
does not produce the same binary with a single linker pass
A question maybe not related to the flipped memory layout, but still interesting.
Is there a way to use flip-link in a Github Action, without building it from source every time?
See https://github.com/Neotron-Compute/Neotron-BMC/runs/3152027601?check_suite_focus=true as an example.
There's been substantial improvement over the past 5 months since the last crates.io release. We're using the latest on master for SoloKeys with no issue, but can't make use of the 5 month old release.
Thank you for this awesome tool!
Let’s say I have a memory.x
containing:
MEMORY
{
FLASH : ORIGIN = 0x00200000, LENGTH = 2M
RAM : ORIGIN = 0x20000000, LENGTH = 32K /* Use only SRAM1. */
}
Trying to use flip-link 0.1.7
gives me the following error:
= note: thread 'main' panicked at 'internal error: entered unreachable code', src/main.rs:341:18
stack backtrace:
0: 0x55a78cf0a0d0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h0f67236053551eca
1: 0x55a78cf2f38f - core::fmt::write::h13a8faf14f1ccf50
2: 0x55a78cf02f67 - std::io::Write::write_fmt::ha1e4f1bb6310f8b3
3: 0x55a78cf09ed5 - std::sys_common::backtrace::print::hda0e459003c3497e
4: 0x55a78cef0e81 - std::panicking::default_hook::{{closure}}::h9fb0f39f8a4b4896
5: 0x55a78cef0b1f - std::panicking::default_hook::h74777d9c83f82eb3
6: 0x55a78cef1329 - std::panicking::rust_panic_with_hook::h5a53706624030272
7: 0x55a78cf0a371 - std::panicking::begin_panic_handler::{{closure}}::h3941e21c138a8c98
8: 0x55a78cf0a1a6 - std::sys_common::backtrace::__rust_end_short_backtrace::h5d3e0e241a65e49e
9: 0x55a78cef1052 - rust_begin_unwind
10: 0x55a78ced1453 - core::panicking::panic_fmt::h396c35e980c19b34
11: 0x55a78ced14e3 - core::panicking::panic::h130b83b9706be6f0
12: 0x55a78ced5371 - flip_link::perform_addition::h0f363ddbf86b6093
13: 0x55a78ced4842 - flip_link::main::h1ef3404106dd9ce7
14: 0x55a78ced9fe3 - std::sys_common::backtrace::__rust_begin_short_backtrace::hd8d493c30b3f63da
15: 0x55a78ced9ff9 - std::rt::lang_start::{{closure}}::had3ef76cc40faa10
16: 0x55a78cee81b7 - std::rt::lang_start_internal::h7910e71d80e7bec3
17: 0x55a78ced5445 - main
18: 0x7f297e27efce - __libc_start_call_main
19: 0x7f297e27f089 - __libc_start_main_impl
20: 0x55a78ced1a35 - _start
21: 0x0 - <unknown>
Removing the comment from the memory.x
or rolling back to flip-link 0.1.6
makes the issue disappear.
flip-link
should support comments in the linker script.
probe-run and defmt have bors, so this repo also should
Maybe a command line interface that looks like this:
flip-link $actual_linker_arguments --linker=arm-none-eabi-gcc
Where --linker
may appear in any position. flip-link
will use arm-none-eabi-gcc
as the linker.
This way the user species flip-link
in their config.toml like this:
# .cargo/config.toml
rustflags = [
"-C", "linker=flip-link",
"-C", "link-arg=--linker=arm-none-eabi-gcc", # <- may appear in any position
"-C", "linker-flavor=gcc", # <- not passed to the linker
# ..
]
flip-link
passes extra linker arguments to the underlying linker.
It currently assumes the linker flavor is "ld". If you want to use gcc
those extra linker arguments need to be prefixed by -Wl,
(iirc), i.e. -Wl,--defsym=something
instead of just --defsym=something
.
flip-link
will not see the -C linker-flavor
passed to rustc
. Should the user also pass a --linker-flavor
argument to flip-link
?
It would be great if we could automatically generate our CHANGELOG.md
instead of maintaining it by hand.
There are a few tools for that, one of them being git-cliff
1. It would make sense to use it, since it is integrated in release-plz
2, but we disabled it at the moment.
We could update the CHANGELOG for every commit being released on master, but I think it makes more sense to just do it on the release. Also this is the behavior from release-plz.
The problem with git-cliff
is that it expects conventional commits3, which we do not have and therefore it generates a broken CHANGELOG. So we need to configure it through the git-cliff.toml
in a way that it can handle our commit messages.
Currently this only checks for overflows in single-ram region called RAM
.
Eventually it would be awesome to support multi region layouts like:
MEMORY
{
RAM : org = 0x20000000, len = 96k /* SRAM1 */
RAM2 : org = 0x10000000, len = 32K /* SRAM2 */
}
The "line-by-line" parser only looks for RAM: org = ...
, but I am not sure if this is the actual blocker?
Also minor side issue;
This line:
Line 61 in e123f17
MEMORY.RAM not found after scanning linker scripts
? Missing the notIt seems that it is possible to take advantage of SIZEOF
of other sections in order to achieve the same
functionality that flip-link
achieves through a small custom section and overriding of _stack_start
:
.stack (NOLOAD) : {
. = ORIGIN(RAM);
. = ORIGIN(RAM) + LENGTH(RAM)
- SIZEOF(.bss)
- SIZEOF(.data)
- SIZEOF(.uninit)
;
} > RAM
_stack_start = ORIGIN(RAM) + SIZEOF(.stack);
This also has the advantage of working with custom linker sections (by adding a -SIZEOF(section)
to the ALIGN
and region aliases.
I am posting to discuss possible issues and tradeoffs of this approach.
Add regression test for #22.
test-flip-link-app
)memory.x
file -- easiest way to do this may be to not use a HALmemory.x
use an INCLUDE
like this:MEMORY
{
FLASH : ORIGIN = 0x00000000, LENGTH = 256K
RAM : ORIGIN = 0x20000000, LENGTH = 64K
}
INCLUDE empty.x
empty.x
file next to the memory.x
When I try to use alloc-cortex-m
in the following fashion:
#![no_main]
#![no_std]
#![feature(alloc_error_handler)]
extern crate alloc;
use alloc_cortex_m::CortexMHeap;
use core::alloc::Layout;
use defmt::*;
#[global_allocator]
static ALLOCATOR: CortexMHeap = CortexMHeap::empty();
#[cortex_m_rt::entry]
fn main() -> ! {
defmt::timestamp!("{=usize}", now());
info!("initializing heap");
let start = cortex_m_rt::heap_start() as usize;
let size = 4;
debug!("start = {:#010x}, size = {:#010x}", start, size);
unsafe { ALLOCATOR.init(start, size) }
// other code
}
Then the program panics immediately upon trying to initialize the heap, and the heap start address appears to be wrong (I am using the STM32F411, so SRAM begins at 0x2000 0000
and ends at 0x2002 0000
).
Finished dev [unoptimized + debuginfo] target(s) in 3.78s
Running `probe-run --chip STM32F411VETx target/thumbv7em-none-eabihf/debug/tasks`
(HOST) INFO flashing program (49 pages / 49.00 KiB)
(HOST) INFO success!
────────────────────────────────────────────────────────────────────────────────
0 INFO initializing heap
└─ tasks::__cortex_m_rt_main::_ @ src/bin/tasks.rs:28
0 DEBUG start = 0x2001fffc, size = 0x00000004
└─ tasks::__cortex_m_rt_main::_ @ src/bin/tasks.rs:33
────────────────────────────────────────────────────────────────────────────────
stack backtrace:
0: HardFaultTrampoline
<exception entry>
1: linked_list_allocator::hole::HoleList::new
at /home/ibiyemi/.cargo/registry/src/github.com-1ecc6299db9ec823/linked_list_allocator-0.8.11/src/hole.rs:50:9
2: linked_list_allocator::Heap::init
at /home/ibiyemi/.cargo/registry/src/github.com-1ecc6299db9ec823/linked_list_allocator-0.8.11/src/lib.rs:73:22
3: alloc_cortex_m::CortexMHeap::init::{{closure}}
at /home/ibiyemi/.cargo/registry/src/github.com-1ecc6299db9ec823/alloc-cortex-m-0.4.1/src/lib.rs:58:13
4: cortex_m::interrupt::free
at /home/ibiyemi/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-0.7.3/src/interrupt.rs:64:13
5: alloc_cortex_m::CortexMHeap::init
at /home/ibiyemi/.cargo/registry/src/github.com-1ecc6299db9ec823/alloc-cortex-m-0.4.1/src/lib.rs:57:9
6: tasks::__cortex_m_rt_main
at src/bin/tasks.rs:35:14
7: main
at src/bin/tasks.rs:24:1
8: Reset
(HOST) WARN call stack was corrupted; unwinding could not be completed
(HOST) ERROR the program panicked
If I disable flip-link
by commenting out "-C", "linker=flip-link"
in .cargo/config.toml
, then this panic does not happen, and a more reasonable start address is printed:
Finished dev [unoptimized + debuginfo] target(s) in 52.83s
Running `probe-run --chip STM32F411VETx target/thumbv7em-none-eabihf/debug/tasks`
(HOST) INFO flashing program (49 pages / 49.00 KiB)
(HOST) INFO success!
────────────────────────────────────────────────────────────────────────────────
0 INFO initializing heap
└─ tasks::__cortex_m_rt_main::_ @ src/bin/tasks.rs:28
0 DEBUG start = 0x20000454, size = 0x00010000
└─ tasks::__cortex_m_rt_main::_ @ src/bin/tasks.rs:33
It has occurred to me that the point of flip-link
is to allow stack overflow errors to be caught by relying on the stack crashing into the RAM boundary. Does this mean that flip-link
is incompatible with the use of a heap, or does the heap need to be placed above the stack in memory? If it's the latter, how would I achieve that?
The pictures used in the Readme have a transparent background with black text. Until recently a perfectly fine choice, but with the newest addition of the Dark Mode in Github, the black text gets invisible. I suggest updating those pictures with a white background.
this linker script works:
MEMORY
{
FLASH : ORIGIN = 0x00000000, LENGTH = 256K
RAM : ORIGIN = 0x20000000, LENGTH = 64K
}
this linker script doesn't work with flip-link, but works with regular LLD
MEMORY
{
FLASH : ORIGIN = 0x00000000, LENGTH = 262144
RAM : ORIGIN = 0x20000000, LENGTH = 65536
}
$ cargo b --bin hello
(..)
= note: rust-lld: error: section '.data' will not fit in region 'RAM': overflowed by 48 bytes
this is probably some issue in the linker script parser
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.