Skip to content

riscv-rt: new attribute macro to define custom _setup_interrupts function.#390

Merged
romancardenas merged 4 commits intorust-embedded:masterfrom
romancardenas:riscv-macros
Apr 13, 2026
Merged

riscv-rt: new attribute macro to define custom _setup_interrupts function.#390
romancardenas merged 4 commits intorust-embedded:masterfrom
romancardenas:riscv-macros

Conversation

@romancardenas
Copy link
Copy Markdown
Contributor

This PR provides the following changes:

  1. New custom-setup-interrupts feature to opt-out the default implementation of _setup_interrupts
  2. Now, instead of defining a _default_setup_interrupts symbol that acts as a weak implementation of _default_setup_interrupts, riscv-rt now directly defines _setup_interrupts (protected under a feature gate). This reduces the amount of code in the final binary when users define their custom interrupt setup routine.
  3. Now, _setup_interrupts can accept an usize input argument that corresponds to the ID of the running hart. This might be useful in multi-hart targets to define hart-specific interrupt setup routines.
  4. New riscv_macros::setup_interrupts attribute macro for aiding users defining their custom interrupt setup routine.

About feature naming

I think custom-setup-interrupts is a clear name for the feature, as it should be activated whenever users want to implement their custom interrupt setup routine. However, previous similar features follow a no-* name (e.g., no-interrupts or no-exceptions). Let me know if you prefer to stick to the no-* naming or if you prefer using custom-*.

While I am currently more inclined to custom-*, I would like to know you opinion.

@romancardenas romancardenas requested a review from a team as a code owner February 9, 2026 13:42
@romancardenas romancardenas requested a review from rmsyn February 17, 2026 15:08
@romancardenas
Copy link
Copy Markdown
Contributor Author

@MabezDev what do you think about calling the feature custom-setup-interrupts instead of no-setup-interrupts? It breaks the current naming convention, but I think it is clearer the purpose of this feature.

@thejpster
Copy link
Copy Markdown

thejpster commented Feb 24, 2026

Wouldn’t the default function be garbage collected by the linker when it observes that it’s unreachable when it’s replaced by another function?

If not, I have problems over in aarch32 land…

@romancardenas
Copy link
Copy Markdown
Contributor Author

romancardenas commented Feb 25, 2026

This full story started with #155

It looks like "default" symbols are not optimized out, and when you override them, you end up having both routines. We have been working on reducing/reusing default symbols to minimize this binary size overhead since then.

As a side note, we experimented with weak symbols in assembly (that was our first approach). However, using weak symbols currently breaks LTO (#247)

@romancardenas romancardenas requested a review from MabezDev March 2, 2026 09:40
@romancardenas
Copy link
Copy Markdown
Contributor Author

@MabezDev @rmsyn I'd appreciate a review so this can be merged and I can move to other contributions

Copy link
Copy Markdown
Member

@MabezDev MabezDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what do you think about calling the feature custom-setup-interrupts

I agree, this is better.

procmacros aren't my expertise, but this looks solid. Thanks!

@romancardenas romancardenas added this pull request to the merge queue Apr 13, 2026
Merged via the queue into rust-embedded:master with commit 2c5813f Apr 13, 2026
165 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants