Re: Supporting RISC-V Vendor Extensions in the GNU Toolchain

[Philipp Tomsich <philipp.tomsich@vrull.eu>]

A generous [snip], as this has been getting a bit long.

On Sun, 15 May 2022 at 03:21, Palmer Dabbelt <palmer@dabbelt.com> wrote:

> I am worried about bad
> actors leveraging any policy to make a bunch of noise, as that's a
> pretty persistent problem in RISC-V land and it looks like things are
> going to get worse before they get better.
>

I don't follow. Maybe you can walk me through the "bad actors" comment next
time we talk…


> > We today have:
> > - Tag_RISCV_arch (see
> >
> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#tag_riscv_arch-5-ntbssubarch
> )
> > - ifunc support
> >
> > Admittedly, there's some loose ends in the end-to-end story (e.g.
> > Unified Discovery -> DTB -> glibc ifunc initialisation): we know just
> > too well how this plays out as there are optimised string/memory
> > functions (Zbb, Zicboz, cache-block-length, …) in our pipeline as well
> > as OpenSSL support for Zbb and Zbc.  However, this is a known gap and
> > will be fully addressed in the future.
> >
> > Is there something specific beyond this that you'd be looking for?
>
> I might be forgetting something, but at least:
>
> * Tag_RISCV_arch attributes are really fundamentally based around
>   compatible extension sets and just don't work when faced with the
>   realities of what RISC-V is today -- that's true even for standard
>   extensions, but it's going to be way worse with vendor extensions.
> * Some scheme that allows relocations from multiple vendors to be linked
>   together.  There's been some proposals here, but nothing that the
>   psABI folks seem to like (and also might not play well with dynamic
>   relocations).
>

I would recommend deferring solving the vendor-defined relocations to a
later time.
All vendor-defined extension proposals already on the table for upstream
inclusion (X-Ventana-CondOps, X-THead-CMO) don't require custom
relocation.  I don't expect anything requiring these shortly — and whoever
submits it will have to provide a proposal for vendor-defined relocations
that finds some consensus.


> * There's a lot between device tree and ifunc (not to mention ACPI).
>   Kito had a proposal for how to get this up to userspace, there's an
>   earlier version from Plumbers last year but there's a lot of work that
>   needs to be done to turn that into reality.
>

Agreed. Our team is looking into this already as Zbb and Zicboz are useful
in GLIBC.


> * Some use cases won't be met by ifunc, there's a whole lot of
>   techniques available and we at least want to allow those to function.
>   In the long run binary compatibility is going to be a losing battle,
>   but we can at least try to keep things sane so the folks in charge at
>   the foundation have a chance to understand what a hole we're in with
>   enough time left to fix it.
>
> I know it's a lot more work to give users the option of compatibility,
> but once that's gone it'll never come back so I'm willing to at least
> try -- though of course that'll put a burden on everyone, even those
> outside the RISC-V ports, so everyone needs to be on board.
>

I have been discussing "fat binaries" on and off in the context of
reconciling the vector fragmentation.
This is a follow-on topic to getting things enabled and ensuring that no
accidental interworking occurs — once the basic support is mature enough, I
hope there will be takers for fat-binary support.

I hope this further clarifies my thinking: I would like to roll support for
vendor-defined extensions out in an incremental manner: starting with
rolling up some extensions into the development tools (assembler, linker,
and compiler); and only then improving runtime detection and library
usage.  For vendor-defined relocations, I would build consensus once we
first encounter the need for them.

Philipp.