cpu/cortexm_common: split interrupt vectors into parts #3540
Conversation
- lets the linker fill the initial stack pointer - splits .vectors into .vectors.common & .vectors.vendor - adds assertions to make sure the layout is correct
- defines the first segment of the NVIC vector tables through vector_common[]. - provides weak defined stubs for *_fault-type exceptions. - provides weak aliases to a dummy handler for isr_*-type exceptions. - changes names from *_fault_default() to *_fault() (nmi_default became isr_nmi)
- only the cpu/vendor specific entries must be specified. - using ISR_VECTORS with an array of exceptions > SysTick will do the right thing. - inserting the initial stack pointer is not necessary anymore.
sgso
changed the title
PeterKietzmann
added
Platform: ARM
| @@ -88,6 +96,15 @@ SECTIONS | |||
| _efixed = .; /* End of text section */ | |||
| } > rom | |||
|
|
|||
| /* Cortex-M expects the initial stack pointer at 0x0. */ | |||
| ASSERT(_stack_base == ORIGIN(rom), | |||
| "ld script assert failed, check cortexm_base.ld for explanation.") | |||
There was a problem hiding this comment.
could you make these assert messages a bit more specific?
|
👍 for this change in general. It is always good to consolidate things to avoid repeating ourselves. |
|
looks good to me |
|
Adressed comments. Can I start adapting the other cpus then? |
|
@sgso yes, go ahead. |
Unfortunately, the assert screws up the output of objdump. This is probably a bug.
|
I took out the assertion completely because it screws up the output of objdump. Anybody knows how to fix it, so that objdump keeps showing the data as .word? For most cpus it was straight-forward. For kinetis I only changed the handler names because it uses its own linker scripts. Somebody with a cc2538 or experience with it should test the new linker script. I don't think the separate linker script is necessary. |
looking better and better :-) |
|
@sgso I don't understand why the asserts would make objdump misbehave. What do you mean by screws up the output? |
|
@gebart I don't know why this is happening:
Same output with |
|
I'm clueless as to the reason of the objdump difference. However, after looking over the linker script again I think it might be better to put the vectors in their own section, like the kinetis scripts do it. It makes it easier to examine the binary with the usual tools, for example |
|
I'm almost sure they will be scrambled like that as well when put in their own sections but there might be a way to mark them as .word-data. I initially opted against this because it does not show up without extra arguments in objdump and might confuse people ("Who stole my vectors?"). I'd like a second opinion because I don't care that much, @haukepetersen? |
|
Just tried, creating two sections .vector_table_common / .vector_table_vendor allows assertions on the size of the common part and does not scramble output. |
Reintroduces assertions
|
I am actually a fan of not putting the vectors in its own section, so it shows up in the default What I would love to see is a unification of linkerscripts between kinetis, cc2538 and the rest of the boards - as said, in either way... But this is not subject of this PR... Regarding the scrambled object dump output: I have no idea... |
|
Please state a reason for closing. |
Proposal that splits the vectors on cortexm_common into a 'common' and a 'vendor specific' part which allows cpu implementations to just specify the vendor entries.