From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 01C703861887 for ; Tue, 6 Oct 2020 17:45:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 01C703861887 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 096HWMIh045223 for ; Tue, 6 Oct 2020 13:45:24 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 340tkbnu2e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 06 Oct 2020 13:45:24 -0400 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 096HXtOg050736 for ; Tue, 6 Oct 2020 13:45:24 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0b-001b2d01.pphosted.com with ESMTP id 340tkbnu2a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Oct 2020 13:45:24 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 096HhPkO002042; Tue, 6 Oct 2020 17:45:23 GMT Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by ppma01dal.us.ibm.com with ESMTP id 33xgx9fj47-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Oct 2020 17:45:23 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 096HjHEo16581046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 6 Oct 2020 17:45:17 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 034CD78066; Tue, 6 Oct 2020 17:45:22 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7EAA27805E; Tue, 6 Oct 2020 17:45:21 +0000 (GMT) Received: from li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com (unknown [9.85.136.107]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTPS; Tue, 6 Oct 2020 17:45:21 +0000 (GMT) Date: Tue, 6 Oct 2020 12:45:19 -0500 From: "Paul A. Clarke" To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 18/28] powerpc64le: Add glibc-hwcaps support Message-ID: <20201006174519.GB105796@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com> References: <01faff4932d02c7e3224b50a1cdb5956354b1fc2.1601569371.git.fweimer@redhat.com> <20201001185639.GA132840@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com> <87ft6txavf.fsf@oldenburg2.str.redhat.com> <20201005191500.GA69013@li-24c3614c-2adc-11b2-a85c-85f334518bdb.ibm.com> <87y2kjsfzu.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y2kjsfzu.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-06_09:2020-10-06, 2020-10-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 lowpriorityscore=0 bulkscore=0 spamscore=0 impostorscore=0 suspectscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010060108 X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Tue, 06 Oct 2020 17:45:26 -0000 On Tue, Oct 06, 2020 at 02:20:21PM +0200, Florian Weimer via Libc-alpha wrote: > * Paul A. Clarke: > > On Mon, Oct 05, 2020 at 11:47:32AM +0200, Florian Weimer wrote: > >> * Paul A. Clarke: > >> >> diff --git a/sysdeps/powerpc/powerpc64/le/dl-hwcaps-subdirs.c b/sysdeps/powerpc/powerpc64/le/dl-hwcaps-subdirs.c > >> >> new file mode 100644 > >> >> index 0000000000..496daf0fa0 > >> >> --- /dev/null > >> >> +++ b/sysdeps/powerpc/powerpc64/le/dl-hwcaps-subdirs.c > > [...snip...] > >> >> +_dl_hwcaps_subdirs_active (void) > >> >> +{ > >> >> + if (GLRO (dl_hwcap2) & PPC_FEATURE2_ARCH_3_1) > >> >> + return 3; > >> >> + > >> >> + if (GLRO (dl_hwcap2) & PPC_FEATURE2_ARCH_3_00) > >> >> + return 1; > > Meh, the second test should do: return 2; 8-( > > Maybe we should write it this way: > > if ((GLRO (dl_hwcap2) & PPC_FEATURE2_ARCH_3_00)) == 0) > return 0; /* No subdirectories active. */ > > if ((GLRO (dl_hwcap2) & PPC_FEATURE2_ARCH_3_1)) == 0) > return 2; /* Only the second directory (power9) is active. */ > > return 3; /* Both directories (power10, power9) are active. */ > > > ...which still creates magic numbers and really doesn't explain what the > > result represents. Even with that rewrite, the "magic numbers" are still there. > > The entire API is documented in a 2-line comment before count_hwcaps(). > > For someone to update the implementation for a new hwcap, which will > > need to be done fairly often, seems to me to be a bit challenging for > > the uninitiated (like me ;-). > > The comments are in elf/dl-hwcaps.h: > > /* Colon-separated string of glibc-hwcaps subdirectories, without the > "glibc-hwcaps/" prefix. The most preferred subdirectory needs to > be listed first. */ > extern const char _dl_hwcaps_subdirs[] attribute_hidden; > > /* Returns a bitmap of active subdirectories in _dl_hwcaps_subdirs. > Bit 0 (the LSB) corresponds to the first substring in > _dl_hwcaps_subdirs, bit 1 to the second substring, and so on. > There is no direct correspondence between HWCAP bitmasks and this > bitmask. */ > int32_t _dl_hwcaps_subdirs_active (void) attribute_hidden; > > >> > Perhaps something like (not tested): > >> > -- > >> > const char * const _dl_hwcaps_subdirs[] = { > >> > #define _DL_HWCAPS_SUBDIR_POWER10_BIT 0x2 /* or 1 to preserve same order. */ > >> > "power10", > >> > #define _DL_HWCAPS_SUBDIR_POWER9_BIT 0x1 /* or 2. */ > >> > "power9" > >> > }; > >> > > >> > int32_t > >> > _dl_hwcaps_subdirs_active (void) > >> > { > >> > int32_t result = 0; > >> > > >> > if (GLRO (dl_hwcap2) & PPC_FEATURE2_ARCH_3_1) > >> > result |= _DL_HWCAPS_SUBDIR_POWER10_BIT; > >> > > >> > if (GLRO (dl_hwcap2) & PPC_FEATURE2_ARCH_3_00) > >> > result |= _DL_HWCAPS_SUBDIR_POWER9_BIT; > >> > > >> > return result; > >> > } > >> > -- > >> > > >> > Of course, that would require changes to the code that parses > >> > _dl_hwcaps_subdirs. > >> > >> I chose the current approach to avoid relocations and memory allocations > >> for processing hwcaps settings (e.g. from the ld.so command line). > > > > Does the "array of strings" approach introduce new/additional relocations > > and memory allocations? It would seem to avoid the need for the splitting > > code, at least. > > The string pointers need runtime relocations (although they probably do > not matter in the grand scheme of things). We still need the splitting > code for the ld.so command line argument. Ah, so you are trying to model the "hwcaps subdirs" on the command-line argument. The latter has to be split to be used, why not allow the subdirs to be "pre-split", then both could be handled as an array of strings? The array for the subdirs could be pre-allocated (if it will always be less than 32 entries) and filled in directly during "active" processing, obviating the need for the mysterious and ephemeral bits indicating "use this"/"don't use this". PC