On Wed, Feb 10, 2021, 5:31 PM Chris Johns <chr...@rtems.org> wrote: > On 11/2/21 3:19 am, Joel Sherrill wrote: > > On Wed, Feb 10, 2021 at 9:58 AM Gedare Bloom <ged...@rtems.org > > <mailto:ged...@rtems.org>> wrote: > > On Wed, Feb 10, 2021 at 7:28 AM Joel Sherrill <j...@rtems.org > > <mailto:j...@rtems.org>> wrote: > > > On Tue, Feb 9, 2021 at 11:20 PM Sebastian Huber > > <sebastian.hu...@embedded-brains.de > > <mailto:sebastian.hu...@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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
