From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id F379C3858D32 for ; Mon, 1 Apr 2024 19:29:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F379C3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F379C3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::42e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711999767; cv=none; b=a+jkRJrIBb9af30dSHuMH2V5oOU8ymUSjNFC96HuCNXl+SXKsciZaEdylpimz5wD8Fr6XqfEpMKFHMhLdKh5SvudJQx+HUOeDng47gh/En4QfT+SJfKQ8LeG6BNIEdI/TmMVVSenzbi7kx0GvRM/FGdpl6327wtxcyvGErRSeT0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711999767; c=relaxed/simple; bh=Gvn2p4pluVqtr8Bd+mCy3t/hoXPGD2IXvARk7xnKcTY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=DnICQovzF0Z1b5SSUxc08BJH8rgNzjMDti7M5OoYaQrYkhq7MgaLP7Kz31u3v+qW1n/wyjEHl4Pu1GPFE5wVVaWA16yj93i8EHDyc+SMpreonM2Y0wr6yHmjE78uae/c4tLHPjXoLkiIAG/A2q7tBMhD7hw5X0EL8MaA+4h8GmA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-6e74aa08d15so3409249b3a.1 for ; Mon, 01 Apr 2024 12:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1711999764; x=1712604564; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=ukkUswLiLV6Vh5CH8W+J6y9NzxFSRoMbtOeqU4xAc/s=; b=E/5x5dXhVvhCRWo39CRW/6FhEssrg2+4gqkZOvQPIGaJncZwFWXzn8OD3qbrpOYKwy Q/A6Qh1yeYRll0XQk10v8zppqQ9u3aQ7RggIpSDP5W7KDxoT/MbmrXjXWA/T1byA/YO8 won6gMHQeowXKqkCCuXfBN6sBAp4/5nemxwCwYjD4/iQ51fwQpuRH0SDpygfz8boriBQ jAgDz2UBxkhycd1nbbDFdMkJa5nZb50DWqSer+L5N61dMLtVaM1NDyNTFUQe9ZnVp+Z+ x7F7UsgRxfVEGKBk1R894DPwmMwm9Ef8kZMshQ4EuI+N+SsAy07j429zDEcjTNzUDym4 RSxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711999764; x=1712604564; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ukkUswLiLV6Vh5CH8W+J6y9NzxFSRoMbtOeqU4xAc/s=; b=Z5Pld5B5yb5R8n2YsDlLFI5IzUfeVAIM1J9mfrDVGkG2FXhoUjBA+M4nJXC3pN21La uwTSO9TpHBWFfekkPwz3a2KeXLV0mnMiCOj4gNxsxD8VtbLbW6+rYR28T8bqJvCykriB TpMjMEY5UUr3W/uC6vjOZkgkqhGFk7rj2WpC1Ksm/veA+3B5DaDJaeCfxA9Szzw+kjlY uFgN80m57MPdv1Cu2iQpvlH7cY5gBuM1GvppkgFjLuRVg190J3HDDfszrtStKMumQeSt w9RL1wA4oOFtwyQj9BvwcKZ7w1mVtAGt8BlCsZjI1hhaPGsoU/pZjZpN8YvUYAW297rG 84MQ== X-Gm-Message-State: AOJu0YyFOi4Ghp7PztNaKCMU2tDBXkxf3KhrMZnnfUtFYA4kLGeav4Ia /hCzBqeaQ7j0kfA/fJvkyRHDJdeAhi7qgJMknLqV8nSpKK047kT/vdrNZPT0kGg= X-Google-Smtp-Source: AGHT+IEayff/EOcIWy96g7bXHC0QU2z5wcsesifZj9XPrZncizlmxjTMVYThTAGv1PNifWazMe193w== X-Received: by 2002:a17:902:7848:b0:1e1:155a:c087 with SMTP id e8-20020a170902784800b001e1155ac087mr11927429pln.28.1711999763911; Mon, 01 Apr 2024 12:29:23 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c3:b18e:bd64:f0b7:697:92fc? ([2804:1b3:a7c3:b18e:bd64:f0b7:697:92fc]) by smtp.gmail.com with ESMTPSA id 12-20020a170902c20c00b001def777afc5sm9308586pll.77.2024.04.01.12.29.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Apr 2024 12:29:23 -0700 (PDT) Message-ID: <37325b3a-f64a-433f-8bc2-e1b0579c8104@linaro.org> Date: Mon, 1 Apr 2024 16:29:20 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 3/3] RISC-V: Implement TLS Descriptors. To: Tatsuyuki Ishi Cc: libc-alpha@sourceware.org, rui314@gmail.com, ruiu@bluewhale.systems, schwab@linux-m68k.org, andrew@sifive.com, fweimer@redhat.com References: <20230817181228.122674-2-ishitatsuyuki@gmail.com> <20240329061834.40019-1-ishitatsuyuki@gmail.com> <20240329061834.40019-4-ishitatsuyuki@gmail.com> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <20240329061834.40019-4-ishitatsuyuki@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 29/03/24 03:18, Tatsuyuki Ishi wrote: > This is mostly based off AArch64 implementation, with some adaptations to > different TLS DTV offsets and calling conventions. > > As we have not officially committed to a vector calling convention, all > vector registers are saved in the calling convention wrapper. This can be > revisited once we decide which registers will be callee-saved. > --- > +/* The fast path does not call function and does not need to align sp, but > + to simplify handling when going into the slow path, keep sp aligned all > + the time. > + */ > +#define FRAME_SIZE_FAST (-((-3 * SZREG) & ALMASK)) > + > +/* The slow path save slot layout, from lower address to higher address, is: > + 1. 32 vector registers > + 2. 12 GP registers > + 3. 20 FP registers > + 4. 3 vector CSR registers > + > + 1. has machine-dependent size, and hence is not included in FRAME_SIZE_SLOW. > + Additionally, the vector register save area needs to be naturally aligned: > + this is satisfied as a side effect of 16-byte stack alignment. > + The size of vector save area, OTOH, also needs to satisfy stack alignment, as > + implementations can have vector registers smaller than 16 bytes. > + For now, the size is guaranteed to be a multiple of 16 as we save all 32 vector registers. > + */ > +#if defined(__riscv_float_abi_soft) > +# define FRAME_SIZE_SLOW (-((-12 * SZREG) & ALMASK)) > +#elif defined(__riscv_vector) > +# define FRAME_SIZE_SLOW (-((-15 * SZREG - 20 * SZFREG) & ALMASK)) We already have 6 different RISC-V abis on build-many-glibcs.py, plus the ZBB/XTHREADB usage on string-fza.h. With this we will another sub-variant we will need to build/check, which will make RISC-V even more MIPS-like with its unfeasible number of ABIs. 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. It could either through ifunc variants, like x86, or by embedding the ABI check within the _dl_tlsdesc_dynamic, like ARM.