From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 8D1643858D20 for ; Fri, 17 May 2024 13:06:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8D1643858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8D1643858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715951181; cv=none; b=aL+RDAr67M8e7F0fEvloz2OLfrdYQGwHP9RTk2KsJhnGiAFP+Ar7G3y+whsSCgdeBKjoBJ0IRWG1oBLgcJLYRxOosfp9JNgme9OzGdmuuo8n/L1K0C+MbIcfm7Sy3hRRL9FAS/CXFDy1zPW+Djar3aX2/LBuqJLxfJiIl49Mf2I= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715951181; c=relaxed/simple; bh=OMqoC2RwG9LXbiXSEWhk0OUY3++likKfX/6E1mTzr08=; h=DKIM-Signature:Message-ID:Date:To:From:Subject:MIME-Version; b=bE9kkUr/yJgkYFMGQoZnV5bntYlPUwX5cyDKhKyugAa8jY+gOlAH3fO1uY0GsdQQX3/A6AyN2J0QRPt6QMVINr4mYysAfdKwTrJ17QB7Y5sIUZCf6cM7dv7jTJ54015NbyPogpuc0xT+H23XqwZJMxxqGJYxVg3VZd0shlGKC0E= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353724.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 44HCHqbQ005278; Fri, 17 May 2024 13:06:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : to : from : subject : cc : content-type : content-transfer-encoding : mime-version; s=pp1; bh=JUikHV5sbhU0VWER5rxnZF5pmrR5qn7Pba0nd0MYbBk=; b=iJF8UpximvIF8FlJyEGBj3ycC4ZVtt5/nenG4258zoO/O42T7B5B0kXkpc7nSWch+HB+ Mzpa7er2nEBzs9JLfgq1qUtT10WzWhuvACKG7Aiyxp3Vhckt6xoTcBG4s81WLcFRYvru 7MzT6aXkKNkTI22P2k3ZHcl2QX7Yy/NY1YYGefzXya1oxJOA4Myv/OV6k49thruF372/ MG0WcxB+u0Skiz+f69ddqYmAOipA2ju/p/7mMYZpJdLp88nDcbQICjGVueGGB7V8+aqk 53zlzVJ3+WZdVGQsZDC+CJybnIXpFVGBhzWw49xlJt0eaQTYlAfUAYSg+yFvk3Yr4bw/ RQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3y67478473-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 May 2024 13:06:11 +0000 Received: from m0353724.ppops.net (m0353724.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 44HCu7G2021261; Fri, 17 May 2024 13:06:10 GMT Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3y67478470-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 May 2024 13:06:10 +0000 Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 44HCpuT5029592; Fri, 17 May 2024 13:06:10 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 3y2n7m7wys-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 May 2024 13:06:10 +0000 Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com [10.20.54.106]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 44HD665x55050622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 17 May 2024 13:06:08 GMT Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7EC8A2004D; Fri, 17 May 2024 13:06:06 +0000 (GMT) Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 244FC20040; Fri, 17 May 2024 13:06:06 +0000 (GMT) Received: from [9.171.90.68] (unknown [9.171.90.68]) by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTP; Fri, 17 May 2024 13:06:06 +0000 (GMT) Message-ID: <6fadccb2-8f24-4aee-aa38-29f0f7918250@linux.ibm.com> Date: Fri, 17 May 2024 15:06:05 +0200 User-Agent: Mozilla Thunderbird Content-Language: en-US To: GNU C Library From: Stefan Liebler Subject: Question regarding platform-bits in ld.so.cache Cc: Florian Weimer , Javier Pello , Adhemerval Zanella Netto Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 4oSZOsqqmFAtnpn-Wrn6sZBmwwa4uPDl X-Proofpoint-GUID: rIk45bVRzCOvnKoJ5k7khM9cXVEzJaU4 Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.11.176.26 definitions=2024-05-17_05,2024-05-17_03,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 priorityscore=1501 adultscore=0 mlxscore=0 suspectscore=0 malwarescore=0 bulkscore=0 mlxlogscore=802 lowpriorityscore=0 spamscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2405010000 definitions=main-2405170103 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,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: Hi, according to the NEWS entry for glibc 2.37: glibc commit "Add NEWS entry for legacy hwcaps removal" https://sourceware.org/git/?p=glibc.git;a=commit;h=78d9a1620b840deb0880686e4159eaf70708866a The dynamic linker no longer no longer loads shared objects from ... or the subdirectory that corresponds to the AT_PLATFORM system name ... But ld.so can still handle ld.so.cache-entries with the platform bits, see elf/dl-cache.c: search_cache(): /* Used by the HWCAP check in the struct file_entry_new case. */ uint64_t platform = _dl_string_platform (GLRO (dl_platform)); if (platform != (uint64_t) -1) platform = 1ULL << platform; uint64_t hwcap_mask = TUNABLE_GET (glibc, cpu, hwcap_mask, uint64_t, NULL); #define _DL_HWCAP_TLS_MASK (1LL << 63) uint64_t hwcap_exclude = ~((GLRO (dl_hwcap) & hwcap_mask) | _DL_HWCAP_PLATFORM | _DL_HWCAP_TLS_MASK); ... if ((libnew->hwcap & hwcap_exclude) && !named_hwcap) continue; if (_DL_PLATFORMS_COUNT && (libnew->hwcap & _DL_HWCAP_PLATFORM) != 0 && ((libnew->hwcap & _DL_HWCAP_PLATFORM) != platform)) continue; For the ld.so.cache platform-bits mechanism, a platform needs _dl_string_platform() returning != -1, _DL_PLATFORMS_COUNT > 0 and _DL_HWCAP_PLATFORM != 0. Thus those architectures are using this mechanism: powerpc, s390, mips, alpha, csky and x86 NOTE: powerpc is using _dl_string_platform() also here: sysdeps/powerpc/hwcapinfo.c:37: __tcb.at_platform = _dl_string_platform (GLRO (dl_platform)); => Within exported symbol __parse_hwcap_and_convert_at_platform. sysdeps/powerpc/test-get_hwcap.c:123: at_platform = _dl_string_platform (at_platform_string); The legacy hwcaps support was removed with those commits: - "elf: Remove legacy hwcaps support from the dynamic loader" https://sourceware.org/git/?p=glibc.git;a=commit;h=6099908fb84debee4c3bcb05d88769410c2aecd1 - "elf: Remove legacy hwcaps support from ldconfig" (glibc 2.37) https://sourceware.org/git/?p=glibc.git;a=commit;h=b78ff5a25dc8ba9d8c6df10bb0a533254bdd193f The latter one also removed creating ld.so.cache-entries with the platform-bits. Is there a plan to also remove the usage in elf/dl-cache.c:search_cache() and perhaps also _dl_string_platform(), _DL_PLATFORMS_COUNT and _DL_HWCAP_PLATFORM at all? Or does it make sense to at least not extend those anymore and perhaps add a comment that ldconfig does not create such entries anymore, but ld.so can still handle old ones? Bye, Stefan