On Thu, Jun 18, 2020 at 8:03 AM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote:
>
>
>
> On Thu, Jun 18, 2020 at 6:34 PM Gedare Bloom <ged...@rtems.org> wrote:
>>
>> On Wed, Jun 17, 2020 at 11:17 PM Utkarsh Rai <utkarsh.ra...@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
>>
>> > 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.
Gedare
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
