[PATCH] sptests/spfatal26: Use an illegal instruction
Joel Sherrill
joel at rtems.org
Thu Jul 19 18:48:11 UTC 2018
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.
--joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180719/a6bb9260/attachment-0002.html>
More information about the devel
mailing list