From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id EB80A3857727 for ; Wed, 4 Oct 2023 11:02:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EB80A3857727 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1c735473d1aso14970855ad.1 for ; Wed, 04 Oct 2023 04:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696417353; x=1697022153; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=/3oXbSz4Vr/TO4F6Fo1F+L1aN+UvHmKyPB5CbaVXPdE=; b=yAtHmAo4pueBKZGOBQKhCwA2AlulvPmIcIBYR6gKOou5cIowkAIkZ2fFljzLTUxSCA JUgQomQ3UoCRWVkvlcIh5Wtasq/ZpsWMe4th102AI51YkEhPxu+x62tU+nm1H1bhKqxc SbaKxhBKp3m7uBYVnP1xcu/8OIZLEMnnlrY9ffNTMPEqrEdlKVFPoVW/5Y1Q+E0g6Jze vFk7iZgslPeI3Md7RgUnMJbmMSuQwS/4cT0uKI9oYXo3MRALJz9xUnqT1TgR+0sbiQa6 zu8tmfd/slQLfM+nOA5RWEa40yFCXA97lwWP9K9Wdmh9qoR2iFGIhxww50CxiWoXefnL 0j5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696417353; x=1697022153; h=content-transfer-encoding:in-reply-to:organization: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=/3oXbSz4Vr/TO4F6Fo1F+L1aN+UvHmKyPB5CbaVXPdE=; b=xJwgNYpamgHnarVIX3Y00P8xOf7C91am9DVepopzc38t3ldE+xXX0EEV/TQ6+dBJqn pyiehnvMqnN59Nb98zpBHpnkpVY7GYHfz2p8Ehy5DhuytkpAMX635V5r4mDJPnVID3ST MzhIjGknEfY4/1WOJPm3HeH/xbngR6oC6EopHBP55Facxp79tuGn8w3ceE1cCTs/ZQer lUlzqm2B74pEpMErH3Uxfi8vPXBszrfPCHAMrMYDYC9hk0Nc4Qq3acYe2tss7faBnS2K zDgR1iUN0s4AJyXJVy8Oe78Aj9eakIHr0UgBVaTzv9sFD0BHht0yIZKBHmZMmxSwKX8I c4+g== X-Gm-Message-State: AOJu0Yzx4awl7irctclMSvTpAvadH4PPXhpKb1+8dvbCKcfLalUUXJ0F fkvxx5be4jEQ3v1uI0R45p1fPw== X-Google-Smtp-Source: AGHT+IHE2lbIz5Y66kYbALC9n6ii47EHeeCGPmVVWRQJyGC4GKJ6zn27JE3pya096RVjF3OIVgPZlQ== X-Received: by 2002:a17:902:c94f:b0:1c3:8464:cabd with SMTP id i15-20020a170902c94f00b001c38464cabdmr2190766pla.12.1696417352641; Wed, 04 Oct 2023 04:02:32 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:feaf:b959:23ff:3a18:c5dc? ([2804:1b3:a7c1:feaf:b959:23ff:3a18:c5dc]) by smtp.gmail.com with ESMTPSA id u16-20020a170902e81000b001bd99fd1114sm3370394plg.288.2023.10.04.04.02.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Oct 2023 04:02:31 -0700 (PDT) Message-ID: Date: Wed, 4 Oct 2023 08:02:28 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries Content-Language: en-US To: Peter Bergner , linux-api@vger.kernel.org, linux-arch@vger.kernel.org, "linuxppc-dev@lists.ozlabs.org" Cc: Nicholas Piggin , Michael Ellerman , Segher Boessenkool , GNU C Library References: <97eb2099-23c2-4921-89ac-9523226ad221@linaro.org> <891957ad-453e-4c68-9c5a-7a979667543d@linux.ibm.com> <057366c2-ee65-441d-b2ac-f40e1d94b44e@linaro.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.2 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 03/10/23 19:12, Peter Bergner wrote: > On 10/3/23 9:08 AM, Adhemerval Zanella Netto wrote: >> What it is not clear to me is what kind of ABI boundary you are trying to >> preemptively add support here. The TCB ABI for __builtin_cpu_supports is >> userland only, so if your intention is just to allow gcc to work on older >> glibcs, it should be a matter to just reserve the space on tcbhead_t. > > Yes, extending tcbhead_t to contain the slots for hwcap3 and hwcap4 are the > ABI extensions we are interested in, and not something that can be backported > into a distro point release. Yes, we don't strictly need the AT_HWCAP3 and > AT_HWCAP4 kernel defines to reserve (and clear) that space in glibc, but.... > > > >> If your intention is to also add support on glibc, it makes more sense to >> already reserve it. For __builtin_cpu_supports it should work, although >> for glibc itself some backporting would be required (to correctly showing >> the bits with LD_SHOW_AUXV). > > Our intention is to also add the glibc support too once we have the > AT_HWCAP3 and AT_HWCAP4 kernel macros defined. 1) Once the defines are > there, adding the support should be pretty straight forward, so why wait? > And 2) part of the glibc and compiler support introduces a new symbol > that is exported by glibc and referenced by the compilers to ensure the > compilers *never* access the hwcap* fields in the TCB unless the glibc > supports them. See the symbol __parse_hwcap_and_convert_at_platform used > for HWCAP/HWCAP2. We'll need a similar one for HWCAP3/HWCAP4 and I'm > doubtful whether the distros will allow the backport of a patch that > introduces a new exported symbol from glibc in a distro point release. Alright, I makes more sense it now. And indeed backporting a __parse_hwcap for HWCAP3/HWCAP4 will be frown upon.