From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id C4ACD1F8C6 for ; Wed, 11 Aug 2021 22:13:12 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 14AF4398B8B5 for ; Wed, 11 Aug 2021 22:13:12 +0000 (GMT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id 0D5EC398B8A6 for ; Wed, 11 Aug 2021 22:11:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0D5EC398B8A6 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pj1-x1029.google.com with SMTP id w13-20020a17090aea0db029017897a5f7bcso7364212pjy.5 for ; Wed, 11 Aug 2021 15:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20150623.gappssmtp.com; s=20150623; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=0C4FJdnSkL4b3MpS5H/ZWwQOpXX/u9uYvh1SPnt+8gA=; b=KBFxqDAOMpJ0Ak6/u7LxGLWqjTfwu4fb8rDa1WroiQv9Y6HkE8pT3oETGwy8PVmwJj 54IJlIrfY/o8RybOKFgheYPmBoE0PYeI6c1FEyvC+XlwkAO7BzwjrpBa0/zQVMN44q1M Krvmv8D2SrlvM9AeirirwpYTf4kIEG76plQt+1Zlgf5Ieklm/KfJS1L1ohYxe+ff94jK pUqCz5Inr1EF4iqygHFIemK94ioI8kpcqTrYlEcYE8VLeQX7nr7qRm5qtP3YNPrVAQ/9 6rgwwRi5mABUNAbJ5fAcEx41thLpoW4bI/+EO3n0ZA+TqHY9Mmyl3x7WH+MCnVSYn4Gh Qvwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=0C4FJdnSkL4b3MpS5H/ZWwQOpXX/u9uYvh1SPnt+8gA=; b=fuXzFe36lVJWYsPK2WIiPdaVQMT0eWXF1bLHU/UHom87YrEcdQetzFqU0euE/T6bTk tq5UlSUWZeZc5HLCTm5xFfw4NZ4kk5KnByPU7eeYXd0UVKxfV6KYsnjHRFhhe8uEhCEO OQLKct3BJMvlHYt+Nha0Ms7pHABK5QfxjwnsSdOUTZIc3HlS7nWdjEGc/6o72DGrXBC+ tQqmdj+yu6jr1ysror/XWqEvPK1/LWOZ+TGhhL1a4YY/FsTQr/tLehPAMB4EkksigPjA 44VXD+X19WaQcJ6r5fXISFohIfDzLvCj9N6Yv6s0N+S4fdW7imtWbMlngjx2/0/esaDE iRWw== X-Gm-Message-State: AOAM5338e+frTF5jXbPzqdXkbY6HLxj/ZaTOi00J2lncukCeEJrZxpzL ZbM5cQ8OX4MhOdcwHlBu7opekWKp8nX+8Q== X-Google-Smtp-Source: ABdhPJzR+3kIkqw6vzfjzZqSwRg8RosAaiJ9nQ9QdfzkQNWq39IRNCw/eySj8GZ0/gEyA0qrz9LABA== X-Received: by 2002:a17:90a:9b13:: with SMTP id f19mr12398160pjp.224.1628719913765; Wed, 11 Aug 2021 15:11:53 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id h11sm556296pfv.154.2021.08.11.15.11.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Aug 2021 15:11:52 -0700 (PDT) Date: Wed, 11 Aug 2021 15:11:52 -0700 (PDT) X-Google-Original-Date: Wed, 11 Aug 2021 15:11:50 PDT (-0700) Subject: Re: [PATCH] riscv: Resolve symbols directly for symbols with STO_RISCV_VARIANT_CC. In-Reply-To: <1628480827-366232-1-git-send-email-kai.wang@sifive.com> From: Palmer Dabbelt To: kai.wang@sifive.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: libc-alpha@sourceware.org, Andrew Waterman , kito.cheng@sifive.com, jrtc27@jrtc27.com Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Sun, 08 Aug 2021 20:47:07 PDT (-0700), kai.wang@sifive.com wrote: > In some cases, we do not want to go through the resolver for function > calls. For example, functions with vector arguments will use vector > registers to pass arguments. In the resolver, we do not save/restore the > vector argument registers for lazy binding efficiency. To avoid ruining > the vector arguments, functions with vector arguments will not go > through the resolver. > > To achieve the goal, we will annotate the function symbols with > STO_RISCV_VARIANT_CC flag and add DT_RISCV_VARIANT_CC tag in the dynamic > section. In the first pass on PLT relocations, we do not set up to call > _dl_runtime_resolve. Instead, we resolve the functions directly. > > The related discussion could be found in > https://github.com/riscv/riscv-elf-psabi-doc/pull/190. I'm trying to stay away from the foundation stuff these days, but from reading that spec it doesn't look like the variant CC has anything to do specifically with the V extension but instead is about allowing for arbitrary calling conventions for X and F registers as well. Handling non-standard X-register calling conventions is really a whole different beast than handling non-standard F or V register calling conventions. It's not crazy to allow for these, but lumping them all into a single bit just makes this unnecessarily difficult. In theory we can handle arbitrary F or V register calling conventions with the standard resolver, we just need to ensure we deal with save/restore of those registers. IMO the right way to go is to just ban F and V register use from the resolver, as there's not much of a reason for them to be in there (none for F, and you probably don't want to spin up the V registers). That just requires sorting out the build system, and would still allow us to have lazy binding for the variants. At a bare minimum we can support arbitrary V register calling conventions for free until we start using the V registers in glibc, which is likely quite a way off. Handling arbitrary X-register calling conventions is a lot tricker: for the fully arbitrary case we can't even have PLT entries, for example. Is there actually a use case for these? If so we'll have to support it, it just seems odd that one would care enough about the X ABI to want a different one while still being able to deal with the overhead of a dynamic call. So I'm not opposed to doing something like this, we just need some way to make sure it's actually solving a problem. > --- > elf/elf.h | 7 +++++++ > sysdeps/riscv/dl-dtprocnum.h | 21 +++++++++++++++++++++ > sysdeps/riscv/dl-machine.h | 26 ++++++++++++++++++++++++++ > 3 files changed, 54 insertions(+) > create mode 100644 sysdeps/riscv/dl-dtprocnum.h > > diff --git a/elf/elf.h b/elf/elf.h > index 4738dfa..0de29bf 100644 > --- a/elf/elf.h > +++ b/elf/elf.h > @@ -3889,6 +3889,13 @@ enum > > #define R_TILEGX_NUM 130 > > +/* RISC-V specific values for the Dyn d_tag field. */ > +#define DT_RISCV_VARIANT_CC (DT_LOPROC + 1) > +#define DT_RISCV_NUM 2 > + > +/* RISC-V specific values for the st_other field. */ > +#define STO_RISCV_VARIANT_CC 0x80 > + > /* RISC-V ELF Flags */ > #define EF_RISCV_RVC 0x0001 > #define EF_RISCV_FLOAT_ABI 0x0006 > diff --git a/sysdeps/riscv/dl-dtprocnum.h b/sysdeps/riscv/dl-dtprocnum.h > new file mode 100644 > index 0000000..f189fd7 > --- /dev/null > +++ b/sysdeps/riscv/dl-dtprocnum.h > @@ -0,0 +1,21 @@ > +/* Configuration of lookup functions. RISC-V version. > + Copyright (C) 2019-2021 Free Software Foundation, Inc. > + This file is part of the GNU C Library. > + > + The GNU C Library is free software; you can redistribute it and/or > + modify it under the terms of the GNU Lesser General Public > + License as published by the Free Software Foundation; either > + version 2.1 of the License, or (at your option) any later version. > + > + The GNU C Library is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + Lesser General Public License for more details. > + > + You should have received a copy of the GNU Lesser General Public > + License along with the GNU C Library. If not, see > + . */ > + > +/* Number of extra dynamic section entries for this architecture. By > + default there are none. */ > +#define DT_THISPROCNUM DT_RISCV_NUM > diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h > index aedf69f..6488483 100644 > --- a/sysdeps/riscv/dl-machine.h > +++ b/sysdeps/riscv/dl-machine.h > @@ -54,6 +54,9 @@ > #define ELF_MACHINE_NO_REL 1 > #define ELF_MACHINE_NO_RELA 0 > > +/* Translate a processor specific dynamic tag to the index in l_info array. */ > +#define DT_RISCV(x) (DT_RISCV_##x - DT_LOPROC + DT_NUM) > + > /* Return nonzero iff ELF header is compatible with the running host. */ > static inline int __attribute_used__ > elf_machine_matches_host (const ElfW(Ehdr) *ehdr) > @@ -299,6 +302,29 @@ elf_machine_lazy_rel (struct link_map *map, ElfW(Addr) l_addr, > /* Check for unexpected PLT reloc type. */ > if (__glibc_likely (r_type == R_RISCV_JUMP_SLOT)) > { > + if (__glibc_unlikely (map->l_info[DT_RISCV (VARIANT_CC)] != NULL)) > + { > + /* Check the symbol table for variant CC symbols. */ > + const Elf_Symndx symndx = ELFW(R_SYM) (reloc->r_info); > + const ElfW(Sym) *symtab = > + (const void *)D_PTR (map, l_info[DT_SYMTAB]); > + const ElfW(Sym) *sym = &symtab[symndx]; > + if (__glibc_unlikely (sym->st_other & STO_RISCV_VARIANT_CC)) > + { > + /* Avoid lazy resolution of variant CC symbols. */ > + const struct r_found_version *version = NULL; > + if (map->l_info[VERSYMIDX (DT_VERSYM)] != NULL) > + { > + const ElfW(Half) *vernum = > + (const void *)D_PTR (map, l_info[VERSYMIDX (DT_VERSYM)]); > + version = &map->l_versions[vernum[symndx] & 0x7fff]; > + } > + elf_machine_rela (map, reloc, sym, version, reloc_addr, > + skip_ifunc); > + return; > + } > + } > + > if (__glibc_unlikely (map->l_mach.plt == 0)) > { > if (l_addr)