Message ID | 1504132534.3182.4.camel@cavium.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 124361 invoked by alias); 30 Aug 2017 22:35:49 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 124352 invoked by uid 89); 30 Aug 2017 22:35:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: NAM02-BL2-obe.outbound.protection.outlook.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Steve.Ellcey@cavium.com; Message-ID: <1504132534.3182.4.camel@cavium.com> Subject: [PATCH][aarch64] Fix hpwcap argument passed to ifunc resolvers From: Steve Ellcey <sellcey@cavium.com> Reply-To: sellcey@cavium.com To: libc-alpha <libc-alpha@sourceware.org> Date: Wed, 30 Aug 2017 15:35:34 -0700 Content-Type: multipart/mixed; boundary="=-aDWfOCYxyvkVAVVJf3tL" Mime-Version: 1.0 X-ClientProxiedBy: MWHPR1201CA0018.namprd12.prod.outlook.com (10.174.253.28) To DM5PR07MB3546.namprd07.prod.outlook.com (10.164.153.144) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fce5793c-61a5-4544-c11a-08d4eff76f25 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR07MB3546; X-Microsoft-Exchange-Diagnostics: 1; DM5PR07MB3546; 3:XzGcqqIzpYc1vgR+6Ek76t5r5dX6yl8w0zJNe4ZUWa4x0sIF3J+wpZ8mlLYZILiII7tyOhcNEmKR4i5YUkM/fHl1WoQq+x4M10mdSUhp/ams5sKwcB5PwKdQ0SMUVKkY0lG5p+Yu2dEIwHMJVy0Ohuegeqnkb7sxSgHoVLnJji9fr7WNqSg/zTkT7CEmaZJoB6MK402+PUrjFQRi2yKW2wkscVAyCdukqxI447KvZh1ob0j4AXULrWDL9MqiAxRA; 25:nu0kU6VUZAdxVAFGv+BTUKTa/+VpGFQ7Y6+tuBrDnRsBsQoCiEsaWqGbbfr5a1RaZHXXt073EAygs0ZwdOyuonVWczgiBR2Tpgtw0EW+0HQ8vYyix0pk1NIymVQ6d9RnFPNN1bRPEU2ORbygJlYrfekqhFTZyvQQke34/128svfCksdC9MPopBSgrTny5Mx6c7LrT9njfLu0Et86DurZUTBg7sAQ+qfJzEmXhm7BkcKGYiKwnmIlSjIysa13w1fxtiFBrCYgU4BUdx7pjax/fTWg2UvBeNVOIlDlXgghzdcj4Inv7FRKuJST3Guu8b/iLkVHmHmUhIeFSXaPMc6rog==; 31:bsqZK0WYDJe311/GfJjPkHINxJV1VdrfxycguwEh06eRhn0TJ8zo6rwcgyY6CjP6ENOto0e/e/6WNnhNUgBIIMd+4fjEpXHegkmVX3ZaLC7AYdFRPsXIAHRqoTf490OFVIV9GdWvQtR8lwaoOQNuOPWtUUVZufjtC2Hv7jn0R11FMpdR12g7DtuU8wymOfMrAkixKHccacjkSPlEWY5XGBfe9rfd/HuA4PSWll97bCY= X-MS-TrafficTypeDiagnostic: DM5PR07MB3546: X-Microsoft-Exchange-Diagnostics: 1; DM5PR07MB3546; 20:DqCJW0L6drk3J43JCk11uIDJF+9qaqhOTGYy9Vad9oiqmy8PDA8znYlasEy2M50pmBNOl6b+fPqhX0erasYdmG4b32qWW7BsD5LB9Q6Fj/C4w8lQM368/kHpdibc7W4G9WXajmRaXH70IJOPY2OH2nt3k5LUBiuQPeCv/GswjMR9A1Po/thVold4lrpN/Fo/Q+ehZDLgDPFTwYqxapQMHudsP/Q/9h0Xfx4sETU5KGgXyeOBKWrwekzgWuMNjkzDT16mwYRIvqaj6+erheGQnfC40tD66CeuW96qduZz5OEbzkKxuIJEg9Yyzd0Zr/CefLGdvK3XC/pDK2YNKxGZ6vECp0B75W0eI6bQ7iSC+uFNDlWauqYg5yis8T4Aq/D36GviOI2J56Pfr3mDz7Bd8T1ppkZGX58zGJrjibrFPSKibKu+od+POtjQyeaXj+BKCQYehmVBckXsni2WsgPkp36AjTkEf4WYexXufKyGRj8Z49zeawR0JSgIcJONn1gh; 4:D3bYfv0JyVyHHrm4WJGl3r+psApDR+QkO0sO7iIobA/NrPFQnhCwN6Wmc7TL6VDoJ3UbYXwjM7J1kfitNBY4HSa8pv9kZzZltB4aEOeN6Jiz2TEZuL/g5lgZ3xu6q7wtkbnBzUigKlC+gPU9iHZSSfYwATtGZusTkwJ9SZ8dERTLsEyfZFW1MnALMF2QI7hhncEhIS+JP41zBHW47bs3O4iwkm7WbNEB+/85GTzoRuSQ1YA7QDmxbKfSHsDLAFpC1g53e41lZ7r4Ko9tmQHis81cu0fyjk0t+xRTl7YDkiyxY00JhDLMS7xz06cXRYEbBE6Roar2OMxSD/sm8pzfYA== X-Exchange-Antispam-Report-Test: UriScan:(22074186197030)(183786458502308); X-Microsoft-Antispam-PRVS: <DM5PR07MB3546AA200629848959CDD6CCF59C0@DM5PR07MB3546.namprd07.prod.outlook.com> X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR07MB3546; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR07MB3546; X-Forefront-PRVS: 041517DFAB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(377424004)(199003)(106356001)(966005)(25786009)(50226002)(105586002)(8676002)(2906002)(103116003)(5660300001)(81166006)(81156014)(8936002)(3450700001)(189998001)(568964002)(305945005)(6116002)(33646002)(512874002)(2476003)(3846002)(110136004)(50986999)(478600001)(43066003)(4610100001)(84326002)(7736002)(36756003)(101416001)(72206003)(5890100001)(6916009)(69596002)(6506006)(97736004)(68736007)(53416004)(6306002)(66066001)(53936002)(6512007)(42186005)(6486002)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR07MB3546; H:sellcey-dt.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR07MB3546; 23:Hl0OF0DhWT4Cw/YrJrIXd99DpnKmtw+9Db0cFrv1U?= =?us-ascii?Q?elmAbI0pUya1Q1eKvLuKN/uc8C8i8d/+gQsJqSwpa38KwI0u2WUpui3ogzlV?= =?us-ascii?Q?N44N04OrRvlnxwXI4toohdlZF/Lad6+u5uhso7yX7byNwlGSwJ6NU+ebGhXM?= =?us-ascii?Q?x8NlDP+dC1BAK9cg3dA6gIzXEdKh4sZyysK69PnIYlrGMHzB5A64xMGtsrQw?= =?us-ascii?Q?LVC8Z0+96fZvOPQNK0pvHBRJF5vDf0ZhxE+lTXtNqseygHMqLj6yAMnRywfB?= =?us-ascii?Q?ceAwKJHqvuOJz4wZMCFKVms3IYXgN0+wOPrk8Ln8PI8wtrrjHO5oIC5PU/VM?= =?us-ascii?Q?0B3QWgVChAIn9w2u/NfuzrhXZGQz1aOul+EG1cm+s2JCSyFrbBxS6MAirFS/?= =?us-ascii?Q?b+4R2qCntMg08fc5iA9D0PlP2f/VyNRsaIf4cXtM9q2IfbrVZq8AAXHYb6mU?= =?us-ascii?Q?BQyngRMhjUFZkXeChNN6N3/76J1QBlq+9l/JyPIEaqcnecC09mHYMAfM/Ubb?= =?us-ascii?Q?beu5p++J6FEPAPYBz4U5RSgT+robzPx+MqnVA1gxJARnde8D4y6+B+o3CUPv?= =?us-ascii?Q?E+BhVWZcofVImmx2XFZY7OixM1g0+vCbyhuuWiWCFVNZIIr9F7jfqN6yoypi?= =?us-ascii?Q?mg7e0lKcbXKkqGryPYO+OEmtQdWMNrA4HsMO3RYK+9Pmdbw8Llx+yFJrQevU?= =?us-ascii?Q?K6YHupxVibXTevSOInBlzjPhBc7Hre+d1JxGboiUh+UJd3mdt5tl9b8Syqk8?= =?us-ascii?Q?oS65OCRc3FlevQ4yxhwLQz4x/qygJUxvATLNLo56+vM+0iMvPeMsaXRGd0R+?= =?us-ascii?Q?tEOe9O9XhT/G36yZUhtNSz+GZSRpTUzJ6iRJBO9c4LiGSj3Z8eUA/GzWMgsJ?= =?us-ascii?Q?atp4R/K2v9CReB1ugYdMODu8EozR08RqPmtkuNoVN5pV6bX9Ko0QmFNK9Wm3?= =?us-ascii?Q?yVGwBI9fb2SiTJokNFX/oDdiBHvgz62rtrwjIP/qSs/O0cMPV9zFpoG53TPB?= =?us-ascii?Q?PZJ6YV/8mknnkfRW6bTCEViljt97l6gbA+joSxF75Wy7JOObP6MiShPN8PDG?= =?us-ascii?Q?sJhdPD+sV1ysT1gkA112ojcONn9H454FwMZJOLrKrDOMTRA4idBEboXADqoB?= =?us-ascii?Q?f04lKXi7s/J+MLidcvVAsRWCEdXWAh0nnIs+dNERv4G3686g8hA3g=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR07MB3546; 6:j+18bqPOBpRaq5jfeHbv1eNgInDl47Gf/Cx58mTft3JIEhSmawJwlR2FFzJ6sJ4Aie6eFx5c95MYP/xTQTx5FeuNGRJTgt/Bcl+mGdzkr18+/RvUVk9UvWh+qsXs+sgngyE6BATTXpgi0f1lHNDh+Ui+pu7NbOvzJJZZ9PcKkgREPqTXsveOKXxIinTQx7cXkEIT6WMcOJqzeVeaX64woptOrW9DIlsTeT06O1PD7ackOldSuj2AaEwJYC/lTR0vVHsP+BUUEGpSUhr6auH+JEkdypqoKbpLX85mflk+BJD3JcK10TF/54s79wgdMZTD0LacTnKlGb/giAvkmsowjw==; 5:4yZu2T26J9Qz8s3aCRaUa50wD1Lh6YgvjwMRVeI/4ZXd3BOzIrsjZvvVwBLWNnN5N+1AqGSNdqw0azztb9DgmFMPD0Z1CoPCl1BvNmNtuWUSHhANSAICgYegv86ToUGdy4asXXE2bJZyEnV3jvk3dA==; 24:4vBciFNIRr2lUnuQl0PhKHQKDFdyzRTY3Hpw2dXrGyZIOXv9LSmYedgXsRITf9Ym0SqCiFqM5a45f4GfnUloQAcL7YVl897N3sboebLeJg8=; 7:7HQ7e8HY/pfSJtxcQuEUlNat0evNbMW1O/O5Ne6w5ygtrwUCcsEDH8d5wsDMH+GC75Nwgv9m7UuSaClYmBZLTji9lpHniHlwyJYP+xzSppArKsk4Hv7rCdqsXpA6dRZogyFccxAjtajNfip07bF9Km3uh9KOKCoH8Js5etsdFCJo1IiuXp2P0Ox7zoFWVcuD8lzxszSp7G5U0ytUDaFe7tYtLYHzDiFLBBO9YmIXdEQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Aug 2017 22:35:36.4600 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR07MB3546 |
Commit Message
Steve Ellcey
Aug. 30, 2017, 10:35 p.m. UTC
I submitted a patch to gcc to use IFUNCs in libatomic. https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00545.html While addressing some of the comments to that patch I realized I needed some changes to glibc in order to enable the functionality correctly. This patch has those changes. In elf_ifunc_invoke I changed the argument type passed to the ifunc resolver function from 'unsigned long int' to 'uint64_t'. This doesn't matter until we do ILP32 but I would like to change it now so that I can check in the gcc patch with a matching type and not have to change it later. The other change here is to use hwcap_mask to mask out the hwcap value passed to the resolver function. This means that ifunc resolvers that use the hwcap argument to check for hardware capabilities will be affected by LD_HWCAP_MASK in the same way that glibc resolver functions are. Finally, I updated HWCAP_IMPORTANT to be all the known HWCAP_* values or'ed together so that nothing was masked out by default. This was set to just HWCAP_CPUID before and if you did not set LD_HWCAP_MASK but tried to check HWCAP_ATOMICS in a ifunc resolver you would get 0 because the default value of hwcap_mask would not have that bit set and it would get masked out by the AND operation I added to elf_ifunc_invoke. I don't think we want any of the hardware capabilities masked out by default, but only if the user sets LD_HWCAP_MASK. Tested on aarch64 with a modified GCC libatomic patch and with the glibc testsuite. Steve Ellcey sellcey@cavium.com 2017-08-30 Steve Ellcey <sellcey@cavium.com> * sysdeps/aarch64/dl-irel.h: Include elf/dl-hwcaps.h for GET_HWCAP_MASK. (elf_ifunc_invoke): Change argument type and use GET_HWCAP_MASK to mask out bits in dl_hwcap. * sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h (HWCAP_IMPORTANT): Use bitwise or of all defined HWCAP values as default value.
Comments
On 30/08/17 23:35, Steve Ellcey wrote: > I submitted a patch to gcc to use IFUNCs in libatomic. > > https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00545.html > > While addressing some of the comments to that patch I > realized I needed some changes to glibc in order to > enable the functionality correctly. This patch has > those changes. In elf_ifunc_invoke I changed the > argument type passed to the ifunc resolver function > from 'unsigned long int' to 'uint64_t'. This doesn't > matter until we do ILP32 but I would like to change > it now so that I can check in the gcc patch with a > matching type and not have to change it later. The > other change here is to use hwcap_mask to mask out > the hwcap value passed to the resolver function. This > means that ifunc resolvers that use the hwcap argument > to check for hardware capabilities will be affected > by LD_HWCAP_MASK in the same way that glibc resolver > functions are. > i'm not yet convinced that LD_HWCAP_MASK should be applied to ifunc resolvers: glibc might be interested in different hwcap flags than external users and the important hwcaps mask has other effect in glibc that i need to review. please do the type change and the masking in separate patches (the libatomic change should work without masking it's just not possible to opt out using an envvar).
On Thu, 2017-08-31 at 16:19 +0100, Szabolcs Nagy wrote: > > i'm not yet convinced that LD_HWCAP_MASK should be > applied to ifunc resolvers: glibc might be interested > in different hwcap flags than external users and the > important hwcaps mask has other effect in glibc that > i need to review. Personally, I like the idea that LD_HWCAP_MASK can affect ifunc resolvers. It gives users a single method to turn off some hardware capability across all libraries. I can see where finer grain control might also be useful but I think that in general we are going to have situations where a particular hardware capability is just not working the way it should and so we want to turn off its use everywhere in an executable. > please do the type change and the masking in separate > patches (the libatomic change should work without masking > it's just not possible to opt out using an envvar). OK, I have sent this off in a seperate thread. https://sourceware.org/ml/libc-alpha/2017-08/msg01355.html Steve Ellcey sellcey@cavium.com
On 08/31/2017 11:12 AM, Steve Ellcey wrote: > On Thu, 2017-08-31 at 16:19 +0100, Szabolcs Nagy wrote: >> >> i'm not yet convinced that LD_HWCAP_MASK should be >> applied to ifunc resolvers: glibc might be interested >> in different hwcap flags than external users and the >> important hwcaps mask has other effect in glibc that >> i need to review. > > Personally, I like the idea that LD_HWCAP_MASK can affect ifunc > resolvers. It gives users a single method to turn off some hardware > capability across all libraries. I can see where finer grain control > might also be useful but I think that in general we are going to have > situations where a particular hardware capability is just not working > the way it should and so we want to turn off its use everywhere in an > executable. I agree with Szabolcs. The use of LD_HWCAP_MASK is a bit of mess in glibc. Problems: * We have one LD_HWCAP_MASK, but two HWCAPs e.g. AT_HWCAP, AT_HWCAP2. * LD_HWCAP_MASK is used for multiple things: * As a filter for ld.so.cache results. * As a filter for multilib directory selection. * We already have sysdeps/aarch64/dl-tunables.list to select glibc.tune.cpu.type. I'd just use the tunables.
On Thu, 2017-08-31 at 18:59 -0500, Carlos O'Donell wrote:
> I'd just use the tunables.
OK, I think using tunables is reasonable. I seem to be having some
trouble with it though, maybe you can tell me if I am doing something
wrong.
On a thunderx box I run a program that calls memcpy, which is an ifunc.
It then calls __memcpy_thunderx the way I think it should.
Then, in the debugger, I run:
set environment GLIBC_TUNABLES=glibc.tune.cpu=generic
I rerun my test program and instead of calling __memcpy_generic (which
it should) or __memcpy_thunderx (which it did before), it calls
__memcpy_falkor, which is totally wrong. Am I setting the variable
incorrectly? I don't see any problems with the IS_FALKOR macro so I
think the problem may be in tunable_is_name unless I am just messing
up how GLIBC_TUNABLES is supposed to be set.
Steve Ellcey
sellcey@cavium.com
I think I found my problem, tunable_is_name returns true if it matches and false if it does not but the use of it in sysdeps/unix/sysv/linux/aarch64/cpu-features.c is: if (tunable_is_name (mcpu, cpu_list[i].name) == 0) It should just be: if (tunable_is_name (mcpu, cpu_list[i].name)) I will send a patch for this once I have tested it. Steve Ellcey sellcey@cavium.com On Fri, 2017-09-01 at 10:22 -0700, Steve Ellcey wrote: > On Thu, 2017-08-31 at 18:59 -0500, Carlos O'Donell wrote: > > > > > I'd just use the tunables. > OK, I think using tunables is reasonable. I seem to be having some > trouble with it though, maybe you can tell me if I am doing something > wrong. > > On a thunderx box I run a program that calls memcpy, which is an > ifunc. > It then calls __memcpy_thunderx the way I think it should. > > Then, in the debugger, I run: > > set environment GLIBC_TUNABLES=glibc.tune.cpu=generic > > I rerun my test program and instead of calling __memcpy_generic > (which > it should) or __memcpy_thunderx (which it did before), it calls > __memcpy_falkor, which is totally wrong. Am I setting the variable > incorrectly? I don't see any problems with the IS_FALKOR macro so I > think the problem may be in tunable_is_name unless I am just messing > up how GLIBC_TUNABLES is supposed to be set. > > Steve Ellcey > sellcey@cavium.com
On 09/01/2017 12:22 PM, Steve Ellcey wrote: > On Thu, 2017-08-31 at 18:59 -0500, Carlos O'Donell wrote: > >> I'd just use the tunables. > > OK, I think using tunables is reasonable. I seem to be having some > trouble with it though, maybe you can tell me if I am doing something > wrong. > > On a thunderx box I run a program that calls memcpy, which is an ifunc. > It then calls __memcpy_thunderx the way I think it should. > > Then, in the debugger, I run: > > set environment GLIBC_TUNABLES=glibc.tune.cpu=generic > > I rerun my test program and instead of calling __memcpy_generic (which > it should) or __memcpy_thunderx (which it did before), it calls > __memcpy_falkor, which is totally wrong. Am I setting the variable > incorrectly? I don't see any problems with the IS_FALKOR macro so I > think the problem may be in tunable_is_name unless I am just messing > up how GLIBC_TUNABLES is supposed to be set. That looks right, you'll have to debug this to see what's going on.
On 09/01/2017 12:30 PM, Steve Ellcey wrote: > I think I found my problem, tunable_is_name returns true if it matches > and false if it does not but the use of it > in sysdeps/unix/sysv/linux/aarch64/cpu-features.c is: > > if (tunable_is_name (mcpu, cpu_list[i].name) == 0) > > It should just be: > > if (tunable_is_name (mcpu, cpu_list[i].name)) > > I will send a patch for this once I have tested it. Thanks. This code is quite new. I expect this was just an oversight of using the new API.
diff --git a/sysdeps/aarch64/dl-irel.h b/sysdeps/aarch64/dl-irel.h index 4a80275..3ef8497 100644 --- a/sysdeps/aarch64/dl-irel.h +++ b/sysdeps/aarch64/dl-irel.h @@ -24,6 +24,7 @@ #include <unistd.h> #include <ldsodefs.h> #include <sysdep.h> +#include <elf/dl-hwcaps.h> #define ELF_MACHINE_IRELA 1 @@ -31,7 +32,8 @@ static inline ElfW(Addr) __attribute ((always_inline)) elf_ifunc_invoke (ElfW(Addr) addr) { - return ((ElfW(Addr) (*) (unsigned long int)) (addr)) (GLRO(dl_hwcap)); + return ((ElfW(Addr) (*) (uint64_t)) (addr)) + (GLRO(dl_hwcap) & GET_HWCAP_MASK()); } static inline void diff --git a/sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h b/sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h index 0333a18..19637f6 100644 --- a/sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h +++ b/sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h @@ -33,9 +33,15 @@ /* Offset of the last bit allocated in HWCAP. */ #define _DL_HWCAP_LAST 15 -/* HWCAP_CPUID should be available by default to influence IFUNC as well as - library search. */ -#define HWCAP_IMPORTANT HWCAP_CPUID +/* HWCAP_IMPORTANT is used to set the default value of hwcap_mask, we do not + want to mask out any HWCAP values because then we could not use them in + an IFUNC selector. */ +#define HWCAP_IMPORTANT (HWCAP_FP | HWCAP_ASIMD | HWCAP_EVTSTRM | HWCAP_AES \ + | HWCAP_PMULL | HWCAP_SHA1 | HWCAP_SHA2 | HWCAP_CRC32 \ + | HWCAP_ATOMICS | HWCAP_FPHP | HWCAP_ASIMDHP \ + | HWCAP_CPUID | HWCAP_ASIMDRDM | HWCAP_JSCVT \ + | HWCAP_FCMA | HWCAP_LRCPC) + static inline const char * __attribute__ ((unused))