knurling-rs / flip-link Goto Github PK

View Code? Open in Web Editor NEW

231.0 14.0 7.0 201 KB

Adds zero-cost stack overflow protection to your embedded programs

License: Apache License 2.0

Rust 99.60% RPC 0.40%

embedded-rust embedded rust tooling rust-tools ferrous-systems linkers

flip-link's People

Contributors

Stargazers

Watchers

Forkers

ain101 linecode joloev icodein sarvex iq-scm nilfit

flip-link's Issues

New release?

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!

CI: verify memory layout of test-app

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:

use the object crate to parse the output ELF
read the .vector_table linker section and extract the initial SP pointer value
find the boundaries of static 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.

subtraction is handled incorrectly

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

Doesn't work with include

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.

Optimize CI

instead of using cargo-generate, just clone the app repo and apply a patch that makes the changes generate would make (saves compile time)
enable windows, mac, nightly builds
set up a cron job to run CI on a daily basis to catch changes in app-template

fix nightlies

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

flip-link doesn't handle LENGTH in bytes

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

supporting other linkers

Unresolved questions

1. How to expose this feature?

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
    # ..
]

2. How to determine the linker flavor?

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?

publish 0.1.0 on crates.io

publish flip-link 0.1.0 on crates.io (also tag on GitHub)

We are on vacation ⛄

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 ❄️

Does not work with `alloc-cortex-m`

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?

flip-link does not respect `memory.x` overrides

Steps to reproduce

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
}

Inspect produced binaries

$ # `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

Compare against 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

Meta

flip-link version

$ cargo install --list | rg ^flip-link
flip-link v0.1.4:

flip-link error

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

unbreak nightlies

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?

GHA support

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.

add CI

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

consider rejecting negative lengths

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

Comments in memory.x are not properly handled

Problem description

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.

Expected behaviour

flip-link should support comments in the linker script.

Handle multiple RAM regions

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:

flip-link/src/main.rs

Line 61 in e123f17

bail!("MEMORY.RAM found after scanning linker scripts");

Should probably read MEMORY.RAM not found after scanning linker scripts ? Missing the not

README talks about defmt

Under Support it mentions defmt instead of flip-link, trivial copy&paste leftover :)

Improve cli argument parsing

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.

Does not support math in RAM origin

This gives the same error as #3

  RAM : ORIGIN = 0x20000000 + 100K, LENGTH = 256K - 100K

while this works

  RAM : ORIGIN = 0x20000000, LENGTH = 256K - 100K

CI: add regression test for #22

Add regression test for #22.

add a new test-app folder / package (like test-flip-link-app)
have this app use a manual memory.x file -- easiest way to do this may be to not use a HAL
have the memory.x use an INCLUDE like this:

MEMORY
{
  FLASH : ORIGIN = 0x00000000, LENGTH = 256K
  RAM : ORIGIN = 0x20000000, LENGTH = 64K
}

INCLUDE empty.x

create an empty empty.x file next to the memory.x
have CI cross compile this new test-app to ARM Cortex-M ("it links" test)

Update Pictures in Readme to display properly in GitHubs darkmode

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.

Set up bors

probe-run and defmt have bors, so this repo also should

How to know RAM runtime usage?

A question maybe not related to the flipped memory layout, but still interesting.

linker `flip-link` not found when using target `thumbv7em-none-eabihf`

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"

cortex-m-rt 0.7.0

Any plan to update flip-link for cortex-m-rt 0.7.x?

Consider using cargo-dist

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.

Automatically generate CHANGELOG

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¹. It would make sense to use it, since it is integrated in release-plz², 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 commits³, 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.