On Fri, Jul 20, 2018 at 10:22 AM, Amaan Cheval <amaan.che...@gmail.com> wrote:
> 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=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@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel