Remaining Waf Conversion Tickets for Community and GSoC Students

[Joel Sherrill]

On Wed, Feb 10, 2021, 5:31 PM Chris Johns <chrisj at rtems.org> wrote:

> On 11/2/21 3:19 am, Joel Sherrill wrote:
> > On Wed, Feb 10, 2021 at 9:58 AM Gedare Bloom <gedare at rtems.org
> > <mailto:gedare at rtems.org>> wrote:
> >     On Wed, Feb 10, 2021 at 7:28 AM Joel Sherrill <joel at rtems.org
> >     <mailto:joel at rtems.org>> wrote:
> >     > On Tue, Feb 9, 2021 at 11:20 PM Sebastian Huber
> >     <sebastian.huber at embedded-brains.de
> >     <mailto:sebastian.huber at embedded-brains.de>> wrote:
> >     >> On 08/02/2021 10:40, Chris Johns wrote:
> >     >
> >     > This brings up a discussion I have been having with Kinsey. He
> submitted BSP
> >     > variants for the aarch64 ilp32 and ip64 multilibs but is heading
> to making
> >     those
> >     > BSP configure options. Not exposing them as variants makes them
> harder to
> >     test.
> >     > It is all the same code and same rtems-tester configuration
> information.
> >     >
> >     +1
> >
> >     > Would we rather have BSP variants for something like this or have
> to layer on
> >     > more code to tweak BSP specific configure options when it really
> does
> >     matter to
> >     > the code generated?
> >     >
> >     > I am happy with clock speeds, memory address ranges, and RAM size
> being
> >     > configure options we don't push through automated testing. Hit the
> defaults
> >     > and move along. But configure options that substantially change
> builds like
> >     > switching the multilib variant feels different.
> >     >
> >     I think a good litmus test is whether or not the source code has to
> change.
> >
> > No source code change for Kinsey's BSPs -- just different GCC settings.
>
> Do these settings change the ABI? I think we need to be careful having
> options
> to vary a BSP's ABI with the same name.
>

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.

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.

I'm leary of configure options not directly derived from bsp variant name
having impacts on code generation like this.


> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210210/4d72634d/attachment-0001.html>