Context switching for protected stacks

[Gedare Bloom]

You can start with the CPP macro you suggest, but eventually we probably
want to make all of this part of application configuration. It is probably
easier to develop using the macros, and then refactor later.

On Thu, Jun 18, 2020, 11:59 PM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:

>
>
> On Fri, Jun 19, 2020 at 3:04 AM Gedare Bloom <gedare at rtems.org> wrote:
>
>> On Thu, Jun 18, 2020 at 8:03 AM Utkarsh Rai <utkarsh.rai60 at gmail.com>
>> wrote:
>> >
>> >
>> >
>> > On Thu, Jun 18, 2020 at 6:34 PM Gedare Bloom <gedare at rtems.org> wrote:
>> >>
>> >> On Wed, Jun 17, 2020 at 11:17 PM Utkarsh Rai <utkarsh.rai60 at gmail.com>
>> wrote:
>> >> >
>> >> > Hello,
>> >> > For my GSoC project, I need to set/unset the memory attributes of
>> the thread stacks on each context switch.
>> >> > Right now I am making changes to the CPU-specific context switch
>> assembly code. The arm/../cpu.h file has the Context_Control structure,
>> which is used to store the relevant registers at each context switch.
>> >> >  I have been trying to add the stack attributes to this structure
>> from the 'rtems/score/stackmanagement.h' header (This header has been
>> defined by me and has the stack attributes structure).
>> >>
>> >> When you change the context structure, there might be other places you
>> >> need to update besides the context switch itself. One that comes to
>> >> mind is _CPU_Context_validate. Maybe chase down where the context is
>> >> referenced.
>> >>
>> >> >  After that, I would initialize the stack attributes in
>> _CPU_Context_Initialize.
>> >> >  For unsetting stack memories, I plan on making changes to
>> _CPU_Context_Switch().
>> >> > The problem is when I try to include the header in cpu.h it breaks
>> the build with the following error -
>> >> >
>> >> > '.......
>> >> > ........
>> >> >
>> /home/utkarsh/sandbox/rtems/5/arm-rtems5/include/machine/_default_types.h:
>> Assembler messages:
>> >> >
>> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:42:
>> Error: junk at end of line, first unrecognized character is `}'
>> >> >
>> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:44:
>> Error: bad instruction `typedef struct stack_attr_prot'
>> >> >
>> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:45:
>> Error: junk at end of line, first unrecognized character is `{'
>> >> >
>> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:46:
>> Error: bad instruction `stack_attr_shared *shared_stacks'
>> >> >
>> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:47:
>> Error: bad instruction `stack_attr Base'
>> >> >
>> /home/utkarsh/sandbox/rtems/cpukit/include/rtems/score/stackmanagement.h:48:
>> Error: bad instruction `_bool current_stack'
>> >> > {standard input}: Error: invalid operands (*UND* and *ABS* sections)
>> for `*' when setting `iter'
>> >> > Makefile:11563: recipe for target
>> 'score/cpu/arm/arm-context-validate.o' failed
>> >> > make[4]: *** [score/cpu/arm/arm-context-validate.o] Error 1
>> >> > '
>> >> > I have defined the stackmanagement.h header in the cpukit/headers.am
>> and this is obviously an assembler error.  Can someone point out what is it
>> that I am doing wrong?
>> >> >
>> >>
>> >> When a .h file can be included in both C and ASM, you need to separate
>> >> some of it, and disable some of it in ASM scope that doesn't
>> >> understand C data types. See, for example,
>> >> cpukit/include/rtems/score/percpu.h
>> >>
>>
>
> Thank you, this solves the problem.
>
>
>> >> > I also would like to verify if the above way of handling context
>> switching is the appropriate way to proceed.
>> >>
>> >> Seems like the right general idea. We probably need a CPP switch to
>> >> enable/disable this stuff though.
>> >
>> >
>> > Can you please elaborate on CPP switch? I am not sure if I am clear
>> about this.
>>
>> Yeah, my reply was a little short. CPP for C Preprocessor. A CPP
>> switch is used for conditional compilation of code, something like
>>
>> #if defined(USE_MMU)
>> ... /* some MMU related code */
>> #else
>> ... /* something without using MMU */
>> #endif
>>
>> This way high-level features can control which code gets compiled into
>> the binary image. This works pretty well for coarse-grained features.
>> It is not that useful for finer-grained features, like you might not
>> want to have USE_MMU_2K_PAGES and USE_MMU_4K_PAGES and
>> USE_MMU_4M_PAGES instead it would be better to have USE_MMU and within
>> that scope provide some way to distinguish the page sizes. I hope that
>> makes some sense.
>>
>> Another example is ASM. We have #if ASM to control whether a header
>> has been included in an assembler source file.
>>
>
> Thank you, this makes it clear. Also, if we are using CPP switches for
> switching to MMU related code, I wonder what should be the high-level
> configuration option that should be provided to the user. A very naive way
> can be if the user defines something like-
>  #define USE_THREAD_STACK_PROTECTION
>
> and then the places where we need to handle for thread stack protection we
> can proceed as you illustrate above.
>
> Gedare
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200619/b60dc3a3/attachment.html>