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. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
