On Thu, Jul 19, 2018 at 1:37 PM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> > > ----- Am 19. Jul 2018 um 17:03 schrieb joel j...@rtems.org: > > > On Thu, Jul 19, 2018 at 8:49 AM, Gedare Bloom <ged...@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.hu...@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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
