Skip to content
This repository has been archived by the owner on Jan 24, 2022. It is now read-only.

[ARMv6-M] initialize the LR register #292

Merged
merged 2 commits into from
Sep 4, 2020
Merged

[ARMv6-M] initialize the LR register #292

merged 2 commits into from
Sep 4, 2020

Conversation

japaric
Copy link
Member

@japaric japaric commented Sep 2, 2020

the ARMv6-M Architecture Reference Manual (ARM DDI 0419D) indicates in section
B1.5.5 "Reset behavior" that the LR (Link Register) starts in an unknown state
when the Reset handler is taken and that its "Value must be initialised by
software"

So this PR does that: it initializes the LR register to 0xFFFF_FFFF (-1) first
thing in the Reset handler (only for v6). The manual doesn't say which value to
use so I decided to use the value used by the ARMv7-M (v7 sets LR to 0xFFFF_FFFF
before invoking the Reset handler; see its Architecture Manual for details).

The values of LR (these are pushed onto the stack in function preludes) are used
to unwind the stack (e.g. GDB's backtrace or a future cortex_m_panic_unwind
handler). Having the initial stack frame use a known value on all Cortex-M
variants makes it easier to implement panic_unwind and avoids virtual
unwinders like GDB backtrace trying to unwind beyond the Reset handler

Note that this implementation uses a trampoline that runs before Reset to set
LR on v6. This is required because the prelude of the Reset routine will push
LR onto the stack; we want that LR value to be -1. Calling register::lr::write
from Reset would perform the write after LR has been pushed onto the stack and
that's too late

NOTE this is a PR against v0.6.x. I'm using that branch as 0.6.x is the latest minor release. I can open a PR against master after this one has been approved.

the ARMv6-M Architecture Reference Manual (ARM DDI 0419D) indicates in section
B1.5.5 "Reset behavior" that the LR (Link Register) starts in an unknown state
when the Reset handler is taken and that its "Value must be initialised by
software"

So this PR does that: it initializes the LR register to 0xFFFF_FFFF (-1) first
thing in the Reset handler (only for v6). The manual doesn't say which value to
use so I decided to use the value used by the ARMv7-M (v7 sets LR to 0xFFFF_FFFF
before invoking the Reset handler; see its Architecture Manual for details).

The values of LR (these are pushed onto the stack in function preludes) are used
to unwind the stack (e.g. GDB's `backtrace` or a future `cortex_m_panic_unwind`
handler). Having the initial stack frame use a known value on all Cortex-M
variants makes it easier to implement `panic_unwind` and avoids virtual
unwinders like GDB `backtrace` trying to unwind beyond the `Reset` handler

Note that this implementation uses a trampoline that runs before `Reset` to set
LR on v6. This is required because the prelude of the `Reset` routine will push
LR onto the stack; we want that LR value to be -1. Calling `register::lr::write`
from `Reset` would perform the write after LR has been pushed onto the stack and
that's too late
@rust-highfive
Copy link

r? @therealprof

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive
Copy link

⚠️ Warning ⚠️

  • Pull requests are usually filed against the master branch for this repo, but this one is against v0.6.x. Please double check that you specified the right target!

Copy link
Contributor

@jonas-schievink jonas-schievink left a comment

Choose a reason for hiding this comment

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

LGTM. I'd like to land this in master first though, to avoid having something in v0.6.x that isn't in master.

@japaric
Copy link
Member Author

japaric commented Sep 2, 2020

PR against the main branch: #293

bors bot added a commit that referenced this pull request Sep 2, 2020
293: [ARMv6-M] initialize the LR register r=therealprof a=japaric

NOTE: same as PR #292

the ARMv6-M Architecture Reference Manual (ARM DDI 0419D) indicates in section
B1.5.5 "Reset behavior" that the LR (Link Register) starts in an unknown state
when the Reset handler is taken and that its "Value must be initialised by
software"

So this PR does that: it initializes the LR register to 0xFFFF_FFFF (-1) first
thing in the Reset handler (only for v6). The manual doesn't say which value to
use so I decided to use the value used by the ARMv7-M (v7 sets LR to 0xFFFF_FFFF
before invoking the Reset handler; see its Architecture Manual for details).

The values of LR (these are pushed onto the stack in function preludes) are used
to unwind the stack (e.g. GDB's `backtrace` or a future `cortex_m_panic_unwind`
handler). Having the initial stack frame use a known value on all Cortex-M
variants makes it easier to implement `panic_unwind` and avoids virtual
unwinders like GDB `backtrace` trying to unwind beyond the `Reset` handler

Note that this implementation uses a trampoline that runs before `Reset` to set
LR on v6. This is required because the prelude of the `Reset` routine will push
LR onto the stack; we want that LR value to be -1. Calling `register::lr::write`
from `Reset` would perform the write after LR has been pushed onto the stack and
that's too late

Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
Copy link
Contributor

@therealprof therealprof left a comment

Choose a reason for hiding this comment

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

LGTM

@jonas-schievink
Copy link
Contributor

bors r+

bors bot added a commit that referenced this pull request Sep 2, 2020
292: [ARMv6-M] initialize the LR register r=jonas-schievink a=japaric

the ARMv6-M Architecture Reference Manual (ARM DDI 0419D) indicates in section
B1.5.5 "Reset behavior" that the LR (Link Register) starts in an unknown state
when the Reset handler is taken and that its "Value must be initialised by
software"

So this PR does that: it initializes the LR register to 0xFFFF_FFFF (-1) first
thing in the Reset handler (only for v6). The manual doesn't say which value to
use so I decided to use the value used by the ARMv7-M (v7 sets LR to 0xFFFF_FFFF
before invoking the Reset handler; see its Architecture Manual for details).

The values of LR (these are pushed onto the stack in function preludes) are used
to unwind the stack (e.g. GDB's `backtrace` or a future `cortex_m_panic_unwind`
handler). Having the initial stack frame use a known value on all Cortex-M
variants makes it easier to implement `panic_unwind` and avoids virtual
unwinders like GDB `backtrace` trying to unwind beyond the `Reset` handler

Note that this implementation uses a trampoline that runs before `Reset` to set
LR on v6. This is required because the prelude of the `Reset` routine will push
LR onto the stack; we want that LR value to be -1. Calling `register::lr::write`
from `Reset` would perform the write after LR has been pushed onto the stack and
that's too late

*NOTE* this is a PR against v0.6.x. I'm using that branch as 0.6.x is the latest minor release. I can open a PR against master after this one has been approved.

Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
@bors
Copy link
Contributor

bors bot commented Sep 2, 2020

Build failed:

@therealprof
Copy link
Contributor

Gah!

+curl -L 'https://developer.arm.com/-/media/Files/downloads/gnu-rm/7-2018q2/gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2?revision=bc2c96c0-14b5-4bb4-9f18-bceb4050fee7?product=GNU%20Arm%20Embedded%20Toolchain,64-bit,,Linux,7-2018-q2-update'

@therealprof
Copy link
Contributor

bors r+

bors bot added a commit that referenced this pull request Sep 2, 2020
292: [ARMv6-M] initialize the LR register r=therealprof a=japaric

the ARMv6-M Architecture Reference Manual (ARM DDI 0419D) indicates in section
B1.5.5 "Reset behavior" that the LR (Link Register) starts in an unknown state
when the Reset handler is taken and that its "Value must be initialised by
software"

So this PR does that: it initializes the LR register to 0xFFFF_FFFF (-1) first
thing in the Reset handler (only for v6). The manual doesn't say which value to
use so I decided to use the value used by the ARMv7-M (v7 sets LR to 0xFFFF_FFFF
before invoking the Reset handler; see its Architecture Manual for details).

The values of LR (these are pushed onto the stack in function preludes) are used
to unwind the stack (e.g. GDB's `backtrace` or a future `cortex_m_panic_unwind`
handler). Having the initial stack frame use a known value on all Cortex-M
variants makes it easier to implement `panic_unwind` and avoids virtual
unwinders like GDB `backtrace` trying to unwind beyond the `Reset` handler

Note that this implementation uses a trampoline that runs before `Reset` to set
LR on v6. This is required because the prelude of the `Reset` routine will push
LR onto the stack; we want that LR value to be -1. Calling `register::lr::write`
from `Reset` would perform the write after LR has been pushed onto the stack and
that's too late

*NOTE* this is a PR against v0.6.x. I'm using that branch as 0.6.x is the latest minor release. I can open a PR against master after this one has been approved.

Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
@bors
Copy link
Contributor

bors bot commented Sep 2, 2020

Build failed:

@therealprof
Copy link
Contributor

Hm, genuine error:

error: tests/compile-fail/interrupt-invalid.rs:22: unexpected error: '22:4: 22:7: no variant or associated item 
...
command: "rustc" "tests/compile-fail/interrupt-invalid.rs" "-L" "/tmp" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-C" "prefer-dynamic" "-o" "/tmp/interrupt-invalid.stage-id" "-L" "target/debug" "-L" "target/debug/deps" "-C" "panic=abort" "-L" "/tmp/interrupt-invalid.stage-id.aux" "-A" "unused"

No idea why though.

@jonas-schievink
Copy link
Contributor

rustc error changed, and we don't run CI on PRs to the v0.6.x branch so we didn't see the failure earlier

Copy link
Contributor

@jonas-schievink jonas-schievink left a comment

Choose a reason for hiding this comment

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

bors r=therealprof

@therealprof
Copy link
Contributor

Huh? Why didn't that dismiss the previous review. Will check the configuration.

@bors
Copy link
Contributor

bors bot commented Sep 4, 2020

Build succeeded:

@bors bors bot merged commit 2907763 into v0.6.x Sep 4, 2020
@bors bors bot deleted the v6-init-lr branch September 4, 2020 13:20
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants