<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 20, 2018 at 10:22 AM, Amaan Cheval <span dir="ltr"><<a href="mailto:amaan.cheval@gmail.com" target="_blank">amaan.cheval@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Jul 20, 2018 at 12:18 AM, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br>
><br>
><br>
> On Thu, Jul 19, 2018 at 1:37 PM, Sebastian Huber<br>
> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>brains.de</a>> wrote:<br>
>><br>
>><br>
>><br>
>> ----- Am 19. Jul 2018 um 17:03 schrieb joel <a href="mailto:joel@rtems.org">joel@rtems.org</a>:<br>
>><br>
>> > On Thu, Jul 19, 2018 at 8:49 AM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
>> ><br>
>> >> For now we don't need to generalize this approach or make any kind of<br>
>> >> facility like this available outside of testing.<br>
>> >><br>
>> >> (FYI: 0 is a "nop" on some architectures)<br>
>> >><br>
>> >> Gedare<br>
>> >><br>
>> >> On Thu, Jul 19, 2018 at 9:37 AM, Sebastian Huber<br>
>> >> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-<wbr>brains.de</a>> wrote:<br>
>> >> > I thought about adding a _CPU_Illegal_instruction() function to<br>
>> >> > <rtems/score/cpu.h>. But, do you want such a toxic function in a<br>
>> >> > header<br>
>> >> file<br>
>> >> > or librtemscpu.a? Now it is isolated in the test and can do no harm.<br>
>> >><br>
>> ><br>
>> > I have wondered if there enough architectural oddities like this in<br>
>> > the tests where a central place to address them would be helpful<br>
>> > when porting.<br>
>><br>
>> I am not really happy about the use of architecture defines in the tests.<br>
>> I will add a _CPU_Instruction_illegal() and _CPU_Instruction_no_operation(<wbr>)<br>
>> (used by testsuites/sptests/spcache01/<wbr>init.c) to <rtems/score/cpuimpl.h><br>
>> tomorrow.<br>
>><br>
>> ><br>
>> > Where all do you have to check now when porting?<br>
>><br>
>> You always have to check the test results.<br>
><br>
><br>
> I meant how many places in the source do you have to touch that<br>
> you don't expect? For example, RPC has some architecture conditionals<br>
> in it that are easy to forget.<br>
<br>
</div></div>Yep, the xdr_float.c update was definitely not something I expected to<br>
have to do:<br>
<a href="https://git.rtems.org/rtems/commit/?id=76c03152e110dcb770253b54277811228e8f78df" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/<wbr>commit/?id=<wbr>76c03152e110dcb770253b54277811<wbr>228e8f78df</a><br>
<br>
Thankfully, IIRC, it was a compile-time error, so it called attention<br>
to itself pretty easily.<br></blockquote><div><br></div><div>Yep. This should be added to the porting guide.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Others that were unexpected / hard to understand at first for me:<br>
<br>
- Not sure why I need<br>
cpukit/score/cpu/x86_64/<wbr>include/machine/elf_machdep.h and not<br>
important enough<br></blockquote><div><br></div><div>This is a new area and I assume it is for dynamic loading. We should</div><div>find out from Chris and add that to the porting guide.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The bsps/*/*/config/bsp.cfg file and what magic variables affect<br>
compilation of which parts of the system (CPU_CFLAGS vs.<br>
CFLAGS_OPTIMIZE_V)<br>
- The hacky use of bsp_specs to override some GCC defaults (the<br>
inclusion of the default crt0 earlier, with __getreent being redefined<br>
erroneously)<br></blockquote><div><br></div><div>Hopefully these two area will improve. </div><div><br></div><div>Hang around after GSoC and maybe you will see them disappear. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- How our GCC toolchains implicitly have "-lrtemsbsp -lrtemscpu" for<br>
when -qrtems is used[1]<br>
<br>
[1] <a href="https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rtems.h#L41" rel="noreferrer" target="_blank">https://github.com/gcc-mirror/<wbr>gcc/blob/master/gcc/config/<wbr>rtems.h#L41</a></blockquote><div><br></div><div>I think this is not so bad but non-obvious.</div><div><br></div><div>The inconsistent and hacky use of bsp_specs needs to disappear.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
><br>
> --joel<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
> ______________________________<wbr>_________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>