[PATCH] sptests/spfatal26: Use an illegal instruction

[Joel Sherrill]

On Fri, Jul 20, 2018 at 10:22 AM, Amaan Cheval <amaan.cheval at gmail.com>
wrote:

> 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=76c03152e110dcb770253b54277811
> 228e8f78df
>
> Thankfully, IIRC, it was a compile-time error, so it called attention
> to itself pretty easily.
>

Yep. This should be added to the porting guide.


>
> 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
>

This is a new area and I assume it is for dynamic loading. We should
find out from Chris and add that to the porting guide.


> - 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)
>

Hopefully these two area will improve.

Hang around after GSoC and maybe you will see them disappear. :)


> - 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


I think this is not so bad but non-obvious.

The inconsistent and hacky use of bsp_specs needs to disappear.


>
>
> >
> > --joel
> >
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180720/97fe04ff/attachment-0002.html>