-
Notifications
You must be signed in to change notification settings - Fork 85
Conversation
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
r? @therealprof (rust_highfive has picked a reviewer for you, use r? to override) |
|
There was a problem hiding this 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.
PR against the main branch: #293 |
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>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
bors r+ |
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>
Build failed: |
Gah!
|
bors r+ |
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>
Build failed: |
Hm, genuine error:
No idea why though. |
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bors r=therealprof
Huh? Why didn't that dismiss the previous review. Will check the configuration. |
Build succeeded: |
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 futurecortex_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 virtualunwinders like GDB
backtrace
trying to unwind beyond theReset
handlerNote that this implementation uses a trampoline that runs before
Reset
to setLR on v6. This is required because the prelude of the
Reset
routine will pushLR 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 andthat'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.