[PATCH] build-many-glibcs: Add a RISC-V config with most of the B extensions

[Florian Weimer]

* Palmer Dabbelt:

> On Wed, 06 Sep 2023 13:43:08 PDT (-0700), fweimer@redhat.com wrote:
>> * Palmer Dabbelt:
>>
>>> +        self.add_config(arch='riscv64',
>>> +                        os_name='linux-gnu',
>>> +                        variant='rv64imafdcb-lp64d',
>>> +                        gcc_cfg=['--with-arch=rv64imafdc_zba_zbb_zbs', '--with-abi=lp64d',
>>> +                                 '--disable-multilib'])
>>
>> I doubt we need a separate GCC configuration, you should be able to use
>> the existing compiler for that and just change the glibc build flags.
>
> Right now we're building a different GCC for each target, setting the
> default arch at GCC configure time.  I agree that's super inefficient,
> but it's what the other tagets do.  Sharing GCCs will also result in
> mixing up things like libgcc, which is kind of a double-edged sword.

It's more mixed, see the power4 variant of powerpc-linux-gnu for an
example.

>> I expect we need some sort of version check because these flags are
>> rather recent, right?  To what extend do they actually impact code
>> generation for glibc?
>
> We've got two inline asm routines that use the B extensions (both Zbb):
>
> sysdeps/riscv/string-fza.h:#if defined __riscv_zbb || defined __riscv_xtheadbb
> sysdeps/riscv/string-fzi.h:#if defined __riscv_zbb || defined __riscv_xtheadbb
>
> That's a pretty small diff, but it is code we're not testing -- not
> sure if that's worth a whole test config, though.

You can add IFUNCs and compile the affected string functions twice, then
code *will* be compiled in a default build, revealing syntax and other
errors.

> On the compiler side the B extensions have a pretty big impact on
> codegen: they add a bunch of common bit manipulation patterns
> (sign/zero extension, bit fields, C strings, etc).  None of that
> should change the ABI, so in theory we should be safe if the GCC test
> suite passes.  We do glibc builds as part of the GCC testing, but that
> usually targets released glibc versions so stuff might slip through.

Do the B extensions change the relocation footprint because they add new
instruction encodes?  That's an area where we've sometimes encountered
problems with changes in ISA baselines/compiler flags.

Thanks,
Florian