A generous [snip], as this has been getting a bit long. On Sun, 15 May 2022 at 03:21, Palmer Dabbelt <pal...@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.
