From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id D225A3858CDA for ; Tue, 10 Jan 2023 18:07:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D225A3858CDA Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pl1-x62d.google.com with SMTP id w3so14051469ply.3 for ; Tue, 10 Jan 2023 10:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=k1oYIZUpjUTlOPTFNNXkKi2LbJfMrj3YNY+VpoU4zMM=; b=mbqwk8GcxBUP7bioTWXbBA8JxfvsMrLmUaZgEh8UcuXysZ86H6T7ko3O3EZCApQReq GMKfuWbqwJ5rv9L2nhRRec08ORtrGAeyYbBNkVYB4gBNC9mXSLUrdTEQNCwXWBfl/BCD dj315ca8VWLyVl4GKm/fV+rmWuzw/70gNiwwK/Kt7vyQLf33XAyLIBOovL03qPjOrJ1q WACadJZu7IBkEzU6OLT+e28R5HsPZNsV0LXBsm/ehq4j9xvSdH5pY/Tgf6AAuZauRLEP /gLCHJmvFZgd9irlbg8owfRHvDja5FUKqtRIkWk7qbXNJm/Slc/GtI6q31Kcx0rKLoKI TRRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=k1oYIZUpjUTlOPTFNNXkKi2LbJfMrj3YNY+VpoU4zMM=; b=WtRdllwNqIPQytJhYEMxXk+4y6j6V+b7PwB5mnTNSN6U9Cl7chhjK5wNY30uV6yZkn MAk/IayJxRFNR7hS4qWF1caFpC9rOJb8k87Kc0yJ180Z6w/VWOsovafuDYkJRMdY7TUl rHElMS8NiQdpM2/n5GVIOlm+hO88VxkTfq5elEbgUgQrlICM+uHlyPe/RyZSD8EjBdr6 wltiuL9fUMyApRIRfgjl+ILNwIQvqFHI+2z9ViTAVjYiC+cg/Ktr7nffXkwiX2eOeDuM kfYRqXbJcqYnAeU2RNT4zOuoxeEt4SnFz1V7mBjJ+KkFAk1asJy+KRtyqvef1Rqv/kNO zCJA== X-Gm-Message-State: AFqh2koe6dbtheR0zDJ5+TouptHjtRUfn25A4iMsjQ0LxiTpBynJwR1c O5KjUSO/K6wdGxtY+Vf5N3o3Pg== X-Google-Smtp-Source: AMrXdXs9AvXlmDlRU2QLRSHdBj3XjEIJcmmMN18gQw/tbBFvGoEXPqqWBDl/UmE33CAVdUOXKZSkiA== X-Received: by 2002:a17:902:b414:b0:186:748e:9383 with SMTP id x20-20020a170902b41400b00186748e9383mr64638172plr.46.1673374065721; Tue, 10 Jan 2023 10:07:45 -0800 (PST) Received: from [192.168.50.116] (c-24-4-73-83.hsd1.ca.comcast.net. [24.4.73.83]) by smtp.gmail.com with ESMTPSA id o10-20020a1709026b0a00b001898ee9f723sm8488664plk.2.2023.01.10.10.07.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Jan 2023 10:07:45 -0800 (PST) Message-ID: Date: Tue, 10 Jan 2023 10:07:43 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Auto-enabling V unit and/or use of elf attributes (was Re: Adding V-ext regs to signal context w/o expanding kernel struct sigcontext to avoid glibc ABI break) Content-Language: en-US To: Kito Cheng Cc: Philipp Tomsich , Andy Chiu , Richard Henderson , Vincent Chen , Florian Weimer , Rich Felker , Andrew Waterman , Palmer Dabbelt , =?UTF-8?Q?Christoph_M=c3=bcllner?= , davidlt@rivosinc.com, Arnd Bergmann , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Szabolcs Nagy , Greentime Hu , Aaron Durbin , Andrew de los Reyes , linux-riscv , GNU C Library References: <1631497278-29829-1-git-send-email-vincent.chen@sifive.com> <50c598a6-e3b3-3062-abe7-23a406067533@rivosinc.com> <7430f494-9b43-5e03-c1e9-6b83e2611a11@rivosinc.com> <91ef3c45-165f-d2b3-7c77-322c01802c41@rivosinc.com> <18465ca3-934f-5b3e-170c-1ff0edea3a89@rivosinc.com> <1f8f1d21-4a19-54fe-8b29-bf9e2a8501d7@rivosinc.com> <3a838afe-974b-60bb-a0e5-83e366ec652e@rivosinc.com> From: Vineet Gupta In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Kito, On 1/10/23 05:21, Kito Cheng wrote: > Hi Vineet: > > >> But you are not suggesting that there is a scenario with executable >> built somehow with V instructions (even .byte encoded) but not have that >> info encoded in RV_ATTR_TAG_arch string. And I'd argue that it is user >> error, they need to make sure that -march had 'v' passed to compiler >> and/or assembler. > > The concept of Tag_RISCV_arch attribute is minimal execution > environment requirement of the executable or shared libraries; use > glibc as an example, we can compile glibc with rv64gc only and then it > can contain vector optimized routines like memcpy and memcpy, and > those function are resolved by ifunc, which means only use those > routines when vector extension are available, so the Tag_RISCV_arch > for the glibc is rv64gc, not rv64gcv since V is not minimal execution > environment requirement. I understand where you are coming from. This "minimal" info can be used in a "compile-once-used-multiple" kind of a paradigm where a glibc with V enabled ifunc can still run on non-V hardware. > My expectation is most distro will still distribute with rv64gc for a > while and then optimize function with vector extension for some > libraries, and those vector code will guarded with some runtime check > mechanism maybe IFUNC, so Tag_RISCV_arch for those libraries won't > contain V. Yes bulk of glibc might not have vector code, but those V ifunc routines do and IMO this information needs to be recorded somewhere in the elf. Case in point being the current issue with how to enable V unit. Community wants a per-process enable, using an explicit prctl from userspace (since RV doesn't have fault-on-first use hardware mechanism unlike some of the other arches). But how does the glibc loader know to invoke prctl. We can't just rely on user env GLIBC_TUNABLE etc since that might not be accurate. It needs somethign concrete which IMO can come from elf attributes. If not, do you have suggestions on how to solve this issue ? Granted the case of executable itself using V insns directly is less likely than the linked/dlopen dso, so we can punt this being done in kernel elf loader and do it in the glibc loader for the DT_NEEDED dsos. > It's not clear in psABI spec, but intend to fix in future: > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/292 Please don't change the semantics of Tag_RISCV_arch itself. Keep the minimum if you want, but also have something which reflects the absolute -march used to build. If nothing it can be used to annotate binaries how they were built. Thx, -Vineet