ISR vectors not linked when NOTHING from zinc crate is used.

[mcoffin]

If an application uses nothing from the zinc crate, then the ISR vectors will not be linked, despite the KEEP directive in the linker script.

[mcoffin]

For app that uncovered this, see app_empty from mcoffin/zinc@b9a9d4f

[bharrisau]

I'd prefer to move ISR vectors to PT and zinc_main macros. We currently
simplify things by saying all k20 have the same ISRs, but they really
don't. Even in the same speed grade the peripherals change.

I'll do up a JSON device and board definition for a Teensy and see how that
feels. The makefile or build.rs would ideally also use that info when
creating the linker script, as we again just simplify and overestimate the
number of vendor ISRs (for the size of vector flash).

For app that uncovered this, see app_empty from mcoffin/zinc@b9a9d4f
mcoffin@b9a9d4f

—
Reply to this email directly or view it on GitHub
#295 (comment).

[mcoffin]

I'd prefer to move ISR vectors to PT and zinc_main macros

👍

[mcoffin]

@bharrisau Actually, neither of those macros are a good fit. platformtree can't be used in non-platformtree examples and the zinc_main annotation cannot be used from within platformtree as it's entire purpose is to define a dummy #[start] implementation for those who aren't using platformtree.

If we're going to take the macro-based approach instead of the linker-based approach, then what we really want is a new crate level attribute, zinc_board added to macro_zinc once #288 gets reviewed and lands. This crate-level attribute would emit the ISR vectors. For example, non-platformtree examples could have #![zinc_board="some_board"] and then platformtree examples could just emit that exact same attribute as an item from the platformtree! macro. That way there's no repetition of code.

To be honest, this should really come after some kind of comprehensive "board abstraction" RFC because the second you try to implement that attribute, you're going to run in to the exact same problem that the current platformtree does in that you need a significant amount of macro code for every single board (well for platformtree it's for every platform, but still the same basic problem).

[mcoffin]

One way we could solve that problem is by doing something like the following hack...

quote_item!(cx, include!("path/to/platform/board_isr.rs"));

That way it at least appears as if you're writing native code and not macro code for every board.

[farcaller]

We can also make a little dedicated macro to just build the isr table.

[mcoffin]

Well, that's what zinc_board would be. Maybe a better name would be zinc_isr. The advantage of being a crate-level attribute is being able to enforce invoking it only at the crate level (and I guess, at least to me, it feels more idiomatic).

[mokus0]

I saw this as well, in both the empty and blink_stm32f4 examples. After a while banging my head against the linker script trying to figure out why the heck KEEP wasn't keeping it, I finally thought to look at the linker input (zinc's rlib) and found that ISRVectors was being put in .rodata rather than .isr_vector. Turns out this was a known issue (rust-lang/rust#27467) in rustc, resolved a few days ago. Pulled a new rustc nightly, and it was magically fixed.