On Fri, Jul 20, 2018 at 12:18 AM, Joel Sherrill <j...@rtems.org> wrote: > > > 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.
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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
