From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id 9BB533857377 for ; Mon, 16 May 2022 12:32:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9BB533857377 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-x336.google.com with SMTP id k26so810992wms.1 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=O9uf7c12CmH/tk20Jzr4DqOEyrJ9HW48Lbhn6UDoQ8wCm2CYxZrK8pGFbrk9Ah+aU1 f0Dz511YCzsoiDl0/cRYmSTLYGmtI4FV4buc3gDI6lULgEMaBhh+j/e7u1XzRfZml/lB PJ/jha/S0U1mAwDTDeAaXnJWvAMI+hBAxcutWvI6lqARp4uvAPBWi46rkoXwqVwSZavq ak0Y5oUMlw77n2/y8KJJdesyw5Cj56QIkp7JCapCrhZ4r92z73Q1uTqbPJC/V+grF+D6 LKfQBQW0h3iqwrlkcWYTOt6LpVXZ/i9aRjmiXAN4f5a4J197SbTFFhedeOcDH7UdB48f D6Ew== X-Gm-Message-State: AOAM532Ifln0vQv1E170Y5TQJmNMFnihIUat/rCC5pNFz71a3KXovB/k V3B+uxvcvc9yaQPT5WaDm/4So/kouLPy2c1engr34Q== 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 Cc: cmuellner@gcc.gnu.org, binutils@sourceware.org, gcc-patches@gcc.gnu.org, libc-alpha@sourceware.org, gdb-patches@sourceware.org, gfavor@ventanamicro.com X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2022 12:32:23 -0000 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.