No support for variables in the linker script

[Abestanis]

I have a linker script that contains a variable, and the newest version v0.1.10 fails to parse the linker script because the evaluation logic added in #104 does not take variables into account.

Example linker script with a variable

_stack_guard_size = 0x100;
MEMORY {
    /** ... */
    STACK_GUARD : ORIGIN = 0x20000000, LENGTH = _stack_guard_size
    RAM         : ORIGIN = 0x20000000 + _stack_guard_size, LENGTH = 264K - _stack_guard_size
}

flip-link linker error

error: linking with `flip-link` failed: exit status: 101
  |
  [...]
    = note: thread 'main' panicked at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/flip-link-0.1.10/src/main.rs:353:13:
          Failed to parse expression "0x20000000 + _stack_guard_size" ("0x20000000 + _stack_guard_size"), got error VariableIdentifierNotFound("_stack_guard_size")
          stack backtrace:
             0: rust_begin_unwind
             1: core::panicking::panic_fmt
             2: flip_link::evaluate_expression
             3: flip_link::main
          note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I used that same linker script with old versions of flip-link and they never complained, but I guess variables were never supported so my RAM sizes must have always been wrong?

I'm not sure manually parsing the entire linker script is a good idea, but it would be possible to use a crate to do the parsing. I've found
ldscript-parser which has not received any activity within a year but seems to be very well tested.

I would be willing to provide a PR trying to replace evalexpr with ldscript-parser if you are on board with this approach.
Just checked and ldscript-parser only supports raw values in the origin and length fields, so we can't use it.

[jonathanpallant]

Correct, variables are not supported. I don't know how to support them other than fully evaluating the entire linker script, which is probably out of scope.

If you are using a Cortex-M33 or other processor with stack limit support, you could use that instead.

[Abestanis]

Yeah, all other options that I came up with have big drawbacks:

• We could let the initial linker run first and output the memory map so it can resolve the values for us.
• We could try to search for the missing variable name followed by an equal sign and try to parse the line. This could cover the simple case, but not the complex ones and also might result in wrong values.
• Try to add variable support to ldscript-parser and then use it. This would make us dependent on the other crate, and we still have to implement evaluating the variables, but at least parsing is already implemented and we wouldn't have to maintain it.

If you are using a Cortex-M33 or other processor with stack limit support, you could use that instead.

Unfortunately my processor does not support a stack limit, but thank you for the suggestion. For now I've just inlined my variables in the region definition.