From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 7EDDB3858D28 for ; Tue, 2 Apr 2024 15:25:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EDDB3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7EDDB3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::42a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712071519; cv=none; b=fJOoTWkY7UeXLd4Yx3aMol5sSSnJE7qvkQ6KrNiiWsEz2aNVBhSnhEmbwEEpmeDdpxHLSjzkS+B5ng5iC9lORSxQ+WIT3KchqumQnWJdP9vYhKIV7XDBgQh8eL3MViHADmRmRTKCKrSJ6RGEuLSE74fBYCDxsTkBGbgLOBjzqU4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712071519; c=relaxed/simple; bh=WoYpc+WJevXCXNSd4V5ikXomKH/7wBaGh7lDA2rC0kQ=; h=DKIM-Signature:Date:Subject:From:To:Message-ID:Mime-Version; b=Zsu28bA0YlTAAEHAgyXQsJeDQhPfJDYgJTF+L4GsiuhOuOG0ptGj6o+vLUv8iBgd4QNaaFpM24x7fs8JfYXlbaXy0eRZuoc2S3Kbqd32CAdBjXhlytkPTYHGfzbNp/PUFtoFccg+lmeevycDnjC71DL8rVmlqtj4RXTNMjF5FGc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x42a.google.com with SMTP id d2e1a72fcca58-6e73e8bdea2so4809348b3a.0 for ; Tue, 02 Apr 2024 08:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20230601.gappssmtp.com; s=20230601; t=1712071512; x=1712676312; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=a4hDEvOjfAOU2GZAYbkNJLEugwi6m89rVWIEnfmNneA=; b=EGDGOGJACmn0xdgy9mgQrH/SSBfi4uW8a20s1ESTjWFiCxJ2Hf4owDZ2FUdF1Tx/vf xA48xBm2YMn9HGntXe/rchj+A542LwU9B0T2Q9HzXYmiV2+VmM8m2Cu0gsXnIvK7RKfB 6zkjU51rtkowe+BovhmuS3zjguN8WvyhkZS9ul/D2ezv6WY5Kn43wEUghMOQmDkPRBcy 9wzbAV0P3d0e0cLz1E7IA0U4WNwKYlmzPJIiVUPN2TxQC/sVtzQEywsL7Oj80BPGXtwQ pgHlmEodkh6MzrJxMazkLuoKx3BYgGLB30mME3ugPQEr94TwVK9Rynh3cs26HSFM6mRp DXXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712071512; x=1712676312; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=a4hDEvOjfAOU2GZAYbkNJLEugwi6m89rVWIEnfmNneA=; b=O6F+kw2WEM0823XAFKCCXwhh6e2VWObxY26JWW34KexQdUtKosxFl+pBs0ODx49jXU nWYBAHxxa2/QlBTgf5s0I4CuC6gywqqq4Vuqeaabf/sk/+8tyeCACOFL0EFmWLQFTgh4 imyEVtosF5IlRnYC8Cg+tL4NQyKz4uV2mpfON1vQpMx7rpxdfOuKJJlOv6rxUd9bKUWJ vcEWt5jvTjfCOKuV3Et30borBGMe3Bswmb41lmx0wSOIUUDdxCU0WpLqPlPdsCfyGMut 5Cx3x8+B5bJrhF8wzU0wALNzaJsHmqMy3S3M1CFq45qUMg1lijQ4wwJy+qNFwq+MICD1 3lhw== X-Forwarded-Encrypted: i=1; AJvYcCUUXW/FV3+Q9yMu+u2dq+LNngE/Zmob/PHtxMUypfO3sB0sAnRheEVAKldVBjXsBuiVgvuP08asAW1Xbd4YqnoqiZibL0xj7Arl X-Gm-Message-State: AOJu0YyUTnjmCJvBXM1WIB4pfwp2h9IRoXrvYIo2npAQrztjQlBspjKk iSu3Gkefx2EDYjq8FgudAep5moNhlffI2xJ6QPbe5x9Zvi/lKamzNavwmcAojVk= X-Google-Smtp-Source: AGHT+IEswinqiZm8Dpwo3MUSyy2zq6W5K+BFBgcJ7EZ/6BgNWKfmDclSjoby6TdYTMjkl6M8w+JwEA== X-Received: by 2002:a05:6a00:230a:b0:6ea:f012:469b with SMTP id h10-20020a056a00230a00b006eaf012469bmr12927463pfh.10.1712071512215; Tue, 02 Apr 2024 08:25:12 -0700 (PDT) Received: from localhost ([192.184.165.199]) by smtp.gmail.com with ESMTPSA id v62-20020a626141000000b006e73f400295sm10281391pfb.61.2024.04.02.08.25.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Apr 2024 08:25:11 -0700 (PDT) Date: Tue, 02 Apr 2024 08:25:11 -0700 (PDT) X-Google-Original-Date: Tue, 02 Apr 2024 08:25:09 PDT (-0700) Subject: Re: [PATCH v6 3/3] RISC-V: Implement TLS Descriptors. In-Reply-To: <1d86a4d8-2fb9-42b1-90eb-4c9fbe0c0729@linaro.org> CC: ishitatsuyuki@gmail.com, libc-alpha@sourceware.org, rui314@gmail.com, ruiu@bluewhale.systems, schwab@linux-m68k.org, Andrew Waterman , fweimer@redhat.com From: Palmer Dabbelt To: adhemerval.zanella@linaro.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 02 Apr 2024 06:35:21 PDT (-0700), adhemerval.zanella@linaro.org wrote: > > > On 02/04/24 00:36, Tatsuyuki Ishi wrote: >>> On Apr 2, 2024, at 4:29, Adhemerval Zanella Netto wrote: >>> >>> Maybe a better option, now that glibc has internally riscv_hwprobe >>> support and that RVV is only support for 6.5, to use instead of adding >>> another ABI variant. We might end up with a new ABI variant for the hard-vector calling convention (ie, passing vector registers in arguments) at some point, but that's a little way off. We don't even support it as a base ABI in GCC yet, and it's too late to do something like that for 14. Either way we'd need to make tlsdesc work on systems with the V extension and the soft-vector ABI, which means dynamically probing for it. >> Does this mean that it can be assumed that RVV code will only be executed on an environment that also supports riscv_hwprobe? In that case, I agree that we should switch the RVV path to use feature detection. > > Unless RVV support is backported without backporting riscv_hwprobe as well, > although I expected that RISC-V maintainer would avoid it because the > whole riscv_hwprobe is to enable runtime selection for RVV and alike > features. Ya, that seems like a way to just make headaches. V is particularly tricky because it has use-visible state and thus everything needs to know about it to work. There's also a prctl() for enabling/disabling the V extension at runtime that we'll need to check, but that's in the same spot. >> I suppose the softfp path will remain the same since not all softfp environment will support hwprobe per the reasoning. hwprobe doesn't change anything about the soft float ABI, that needs to be linked with compatible objects in order to function correctly. That's the same spot we'd end up in for the hard-vector ABI, if we added one. > I take that softfp is a de-facto ABI for RISC-V, at least this what we > have on build-many-glibcs.py: > > riscv64-linux-gnu-rv64imac-lp64 > riscv64-linux-gnu-rv64imafdc-lp64 > riscv64-linux-gnu-rv64imafdc-lp64d Ya, we have soft-float and double-float ABIs in glibc. There's also a single-float ABI in GCC, but we decided not to add that to glibc to avoid the complexity. > I am not sure whether RISC-V maintainer would like to move to profilers > or would keep this extensions composability manner. What do you mean by "move to profilers"? "move to profiles"? We have the profiles in RISC-V, but they don't really fix anything here: there's a ton of them, they still have various optional extensions, and the HW support is all over the place (we don't even have compatibility guarantees with individual extensions, for example). So I think for just sticking to the current base ABIs is the way to go. Maybe at some point HW vendors will start shipping systems that are compatible with some common extension set and we can promote that to a new base ABI, but we're a way off from that happening. > >> >> Tatsuyuki.