<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 10, 2021, 5:31 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/2/21 3:19 am, Joel Sherrill wrote:<br>
> On Wed, Feb 10, 2021 at 9:58 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a><br>
> <mailto:<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a>>> wrote:<br>
>     On Wed, Feb 10, 2021 at 7:28 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">joel@rtems.org</a><br>
>     <mailto:<a href="mailto:joel@rtems.org" target="_blank" rel="noreferrer">joel@rtems.org</a>>> wrote:<br>
>     > On Tue, Feb 9, 2021 at 11:20 PM Sebastian Huber<br>
>     <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
>     >> On 08/02/2021 10:40, Chris Johns wrote:<br>
>     ><br>
>     > This brings up a discussion I have been having with Kinsey. He submitted BSP<br>
>     > variants for the aarch64 ilp32 and ip64 multilibs but is heading to making<br>
>     those<br>
>     > BSP configure options. Not exposing them as variants makes them harder to<br>
>     test.<br>
>     > It is all the same code and same rtems-tester configuration information.<br>
>     ><br>
>     +1<br>
> <br>
>     > Would we rather have BSP variants for something like this or have to layer on<br>
>     > more code to tweak BSP specific configure options when it really does<br>
>     matter to<br>
>     > the code generated?<br>
>     ><br>
>     > I am happy with clock speeds, memory address ranges, and RAM size being<br>
>     > configure options we don't push through automated testing. Hit the defaults<br>
>     > and move along. But configure options that substantially change builds like<br>
>     > switching the multilib variant feels different.<br>
>     ><br>
>     I think a good litmus test is whether or not the source code has to change.<br>
> <br>
> No source code change for Kinsey's BSPs -- just different GCC settings.<br>
<br>
Do these settings change the ABI? I think we need to be careful having options<br>
to vary a BSP's ABI with the same name.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I think the answer is yes. One has 32 bit pointers and the other has 64-bit pointers. Based on the bugs Kinsey has found in newlib, the 32-bit code sometimes has to clear the upper bits to ensure valid addresses.</div><div dir="auto"><br></div><div dir="auto">I think these need to be different bsp variants (e.g. names) not configure options. This is how the riscv, sparc, and m68k do it.</div><div dir="auto"><br></div><div dir="auto">I'm leary of configure options not directly derived from bsp variant name having impacts on code generation like this.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Chris<br>
</blockquote></div></div></div>