Ran out of registers during register allocation

[alexmadeathing]

I have a fresh copy of avr-hal-template.git which compiles fine in isolation, but as soon as I move it into its own folder as a child of a workspace and cd into that folder to build, I'm getting Ran out of registers during register allocation error.

I've seen #277 but compiling release gives error language item required, but not found: eh_personality.

Any ideas?

How are people setting up workspaces for multiple targets? I'm looking to target other microcontrollers, such as cortex-m4 (using cortex-m crate). Should I just not use a workspace in this case?

[alexmadeathing]

Update, I was able to compile by moving:

[profile.dev]
panic = "abort"
lto = true
opt-level = "s"

[profile.release]
panic = "abort"
codegen-units = 1
debug = true
lto = true
opt-level = "s"

From the template Cargo.toml (in sub folder) into the workspace Cargo.toml (in the root).

I believe these settings should be good for all my platforms.

One downside is that I can't build the whole workspace (for all platforms) in one cargo build command because the .cargo/config in each subfolder won't get noticed. I presume people are just building each manually? Is there a nice way to handle this without needing to cd around?

[Rahix]

Is there a nice way to handle this without needing to cd around?

I don't know of any, unfortunately... Tbh, I've stopped putting crates for different architectures into one cargo workspace for this reason. I'll just keep each as a separate project.

[alexmadeathing]

Yeah fair enough. I was considering that too. Thanks for the quick reply!

[ghost]

Not sure if this is a good idea, but some of these settings can be encoded in the target specs, e.g.

{
  "panic-strategy": "abort",
  "default-codegen-units": 1,
  "requires-lto": true,
}

That could reduce some of the [profile.dev] and [profile.release] boilerplate.

[Rahix]

Hmm, interesting, I was not aware of this.

For

{"panic-strategy": "abort"}

I think it is a good idea to enforce it through the target spec.

For

{
  "default-codegen-units": 1,
  "requires-lto": true,
}

I am unsure... Yes, 99.9% of AVR projects will need to be compiled with LTO. But then there may be some odd cases where LTO is broken or cannot be used and it would make things much harder to debug if people don't even know about LTO being enabled. Right now, it is very visible by being present in the Cargo.toml file.

Now that I think about it, "hiding" the panic-strategy in the spec file may also make things less obvious than it is now...

Let's hear what other people think about this.