On 16/08/2020 18:09, Utkarsh Rai wrote:
On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom <ged...@rtems.org
<mailto:ged...@rtems.org>> wrote:
On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai
<utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote:
>
>
>
> On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai
<utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote:
>>
>>
>>
>> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom <ged...@rtems.org
<mailto:ged...@rtems.org>> wrote:
>>>
>>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai
<utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote:
>>> >
>>> >
>>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai
<utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote:
>>> >>
>>> >> Thanks, I'll check them out.
>>> >>
>>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom
<ged...@rtems.org <mailto:ged...@rtems.org>> wrote:
>>> >>>
>>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai
<utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote:
>>> >>> >
>>> >>> > Hello,
>>> >>> > I have been testing my code for thread stack isolation
against various tests( Some written by me, and remaining already
present). One of the limitations that I have found is that I
encounter fatal errors whenever a context switch takes place
through an ISR. Can you please explain how the context switching
procedure works when an interrupt occurs. When I use gdb for
stepping through the code it asynchronously moves to context
switching code from the executing thread( for example psx16 test).
>>> >>> > For thread stack protection, the part that deals with
context switching simply 'sets 'the memory entries of the heir
stack and 'unsets' that of the executing stack.
>>> >>>
>>> >>> There are two issues to start: interrupt stacks and
dispatching from an ISR.
>>> >>>
>>> >>> I think you can start by reading some of the documentation:
>>> >>>
https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt
>>> >>>
>>> >>>
https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks
>>> >>>
>>> >>>
https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size
>>> >>>
>>> >>>
https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing
>>> >>>
>>> >>> You can also find some material in rtems-docs.git/porting
-- I don't
>>> >>> know where that gets generated.
>>> >>>
>>> >>> Continue to ask questions, and writing blog posts.
>>> >
>>> >
>>> > So after going through the materials, I was able to
understand how an ISR is registered, ISR stack initialization.
What is still not clear to me is what are the differences between
dispatching a task in ISR different and a normal context-switch?
>>> >
>>> > For example the psxsignal06 test, we wait for a signal
here, on setting the breakpoint at the context switch code
(cpu_asm.S), after this line, I find that the heir context stack
is the ISR stack. The next thread is dispatched from this ISR but
as soon as I unset the memory attributes of the ISR stack I get a
fatal error. One possible reason is that the ISR stack is not page
aligned and unsettling its attributes unsets nearby memory
regions. Is there something else that I am missing?
>>> >
>>> what else is on the same page as the ISR stack?
>>>
>>
>> The idle thread stack is between 0x202e40 to 0x203e40 and the
ISR stack is between 0x203e40 to 0x204e40. So when we unset the
memory for the ISR it unsets between 0x203000 to 0x205000, I think
this may be the problem.
>>
>>
>>>
>>> Not quite related, you'll need to also make sure to map the
ISR stack
>>> back in during ISR Handling, before using it.
>>
>>
>> When the ISR gets called for the first time, it already has R/W
permission and for subsequent context switches it's memory entry
is accordingly set/unset.
>
>
> The idle thread stack and the ISR stack are placed at these
addresses with the BSP specific linker script as "rtemsstack.idle"
and "rtemsstack.interrupt". So to make them page-aligned we may
have to make changes in the lnker script.
Give it a try. It should be relatively easy to hack in a couple of
alignments.
We can discuss later the correctness of that.
Ok, I will report how it goes.
Please use the CPU port option
#define CPU_INTERRUPT_STACK_ALIGNMENT CPU_CACHE_LINE_BYTES
to define the interrupt and idle stack alignment. There is no need to
change the linker command file.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
