From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UzvcE2NEgmKSiAYAWB0awg (envelope-from ) for ; Mon, 16 May 2022 08:32:35 -0400 Received: by simark.ca (Postfix, from userid 112) id 43CFD1E220; Mon, 16 May 2022 08:32:35 -0400 (EDT) Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=vrull.eu header.i=@vrull.eu header.a=rsa-sha256 header.s=google header.b=Gb+jkcnp; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 558FA1E01D for ; Mon, 16 May 2022 08:32:33 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C1B723856DE8 for ; Mon, 16 May 2022 12:32:31 +0000 (GMT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 8812F3857C71 for ; Mon, 16 May 2022 12:32:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8812F3857C71 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=vrull.eu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vrull.eu Received: by mail-wm1-x32f.google.com with SMTP id p5-20020a1c2905000000b003970dd5404dso885292wmp.0 for ; Mon, 16 May 2022 05:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vrull.eu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qHq5M15LTt7pkFriToRwXv3A7shj0RKJnkzJhhcSdZY=; b=Gb+jkcnpq1KOdy8kdklMUIJ4AIqBYaO8Y764UCNxQW+H/0noE7XBemyqnMQlNIDrTl I5aLptN2nGM9j4n4eMlvrmJ/3j2zhZAArKwLp6rCZAcv0K2uft8F8QKTSs9LeLILXcjl CywR0khYlJMRYMWqsSkjeireXBTR8kQ16VHfOXlS7AsdPdvZaLJfTPmR39oHEiAtPm48 hWIUyjvUfrz8gFPabIR8mggaR2G9aldsyfj69KMthnFNRD7DKnXpxOE94qDyqEiu6yAt kd9a/Mptcp+j7AUjNBFHZOtOCJ3VzLmrylrnloS3/3M8RqH0QsZeM/GdRQY7nhN/BFKJ w+fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qHq5M15LTt7pkFriToRwXv3A7shj0RKJnkzJhhcSdZY=; b=fUL9VwJoUrCeUg4pI5NIB/woG+jZnftf1NFk+aKHh5Exyxu/W3taHbwdxIhoH+w4rm eB0n8D4li1TJ0Adt2y3Y/PsRgYnl0TUq/eQTXjLn5mOyxqrG6ETkS3RQntBsU6P2YCR9 FnA5sRRfBlgIYV14chTREdiVfr6w7H6Hoky6bSmuXkGII1ZiqgNFymeR6dHV0KhAtHDc ernF7JLVkRXfG6K67Pr21UPYawEbqh+s3JJHbWsnrrVg0jfFWMVOeOyLICvviRkh7Sty YgF0z63eNhy3vEwR22tzHGA/8VbeQb9mj57cabOSjrrv7SOm89d+dhXQUKpVEpH5vo4w NFvQ== X-Gm-Message-State: AOAM5331s22XJuv+K/EcfAEivFox/3v7l63mCdQu9rVjlT63iDvXDgX2 glOIDJBN6stzivXTypubxAAccfZ632RfnUTpycA6zdjLz044oQ== X-Google-Smtp-Source: ABdhPJzvOC/ZmdWnvAsg8PFOAdMK5PVqQf2AsyofmGJRwKxijSyr/AsjWYETSx+p/AV30qp7qr2x3RbY+7eGSyvJGK4= X-Received: by 2002:a05:600c:3b0a:b0:394:6373:6c45 with SMTP id m10-20020a05600c3b0a00b0039463736c45mr26570877wms.69.1652704337188; Mon, 16 May 2022 05:32:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Philipp Tomsich Date: Mon, 16 May 2022 14:32:05 +0200 Message-ID: Subject: Re: Supporting RISC-V Vendor Extensions in the GNU Toolchain To: Palmer Dabbelt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: libc-alpha@sourceware.org, gfavor@ventanamicro.com, cmuellner@gcc.gnu.org, gcc-patches@gcc.gnu.org, binutils@sourceware.org, gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" A generous [snip], as this has been getting a bit long. On Sun, 15 May 2022 at 03:21, Palmer Dabbelt 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=E2=80=A6 > > We today have: > > - Tag_RISCV_arch (see > > > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-el= f.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, =E2=80=A6) 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 =E2=80=94 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 =E2=80=94 once the basic support is mature e= nough, 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.