[PATCH] sptests/spfatal26: Use an illegal instruction

[Amaan Cheval]

On Fri, Jul 20, 2018 at 12:18 AM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> On Thu, Jul 19, 2018 at 1:37 PM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>>
>>
>>
>> ----- Am 19. Jul 2018 um 17:03 schrieb joel joel at rtems.org:
>>
>> > On Thu, Jul 19, 2018 at 8:49 AM, Gedare Bloom <gedare at rtems.org> wrote:
>> >
>> >> For now we don't need to generalize this approach or make any kind of
>> >> facility like this available outside of testing.
>> >>
>> >> (FYI: 0 is a "nop" on some architectures)
>> >>
>> >> Gedare
>> >>
>> >> On Thu, Jul 19, 2018 at 9:37 AM, Sebastian Huber
>> >> <sebastian.huber at embedded-brains.de> wrote:
>> >> > I thought about adding a _CPU_Illegal_instruction() function to
>> >> > <rtems/score/cpu.h>. But, do you want such a toxic function in a
>> >> > header
>> >> file
>> >> > or librtemscpu.a? Now it is isolated in the test and can do no harm.
>> >>
>> >
>> > I have wondered if there enough architectural oddities like this in
>> > the tests where a central place to address them would be helpful
>> > when porting.
>>
>> I am not really happy about the use of architecture defines in the tests.
>> I will add a _CPU_Instruction_illegal() and _CPU_Instruction_no_operation()
>> (used by testsuites/sptests/spcache01/init.c) to <rtems/score/cpuimpl.h>
>> tomorrow.
>>
>> >
>> > Where all do you have to check now when porting?
>>
>> You always have to check the test results.
>
>
> I meant how many places in the source do you have to touch that
> you don't expect? For example, RPC has some architecture conditionals
> in it that are easy to forget.

Yep, the xdr_float.c update was definitely not something I expected to
have to do:
https://git.rtems.org/rtems/commit/?id=76c03152e110dcb770253b54277811228e8f78df

Thankfully, IIRC, it was a compile-time error, so it called attention
to itself pretty easily.

Others that were unexpected / hard to understand at first for me:

- Not sure why I need
cpukit/score/cpu/x86_64/include/machine/elf_machdep.h and not
important enough
- The bsps/*/*/config/bsp.cfg file and what magic variables affect
compilation of which parts of the system (CPU_CFLAGS vs.
CFLAGS_OPTIMIZE_V)
- The hacky use of bsp_specs to override some GCC defaults (the
inclusion of the default crt0 earlier, with __getreent being redefined
erroneously)
- How our GCC toolchains implicitly have "-lrtemsbsp -lrtemscpu" for
when -qrtems is used[1]

[1] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rtems.h#L41

>
> --joel
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel