Message ID | 20200727092649.31740-1-szabolcs.nagy@arm.com |
---|---|
State | Committed |
Commit | 2dc33b928b389f50e7fd8cadd952b79112a071ab |
Headers |
Return-Path: <libc-alpha-bounces@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8987D386181A; Mon, 27 Jul 2020 09:27:08 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150050.outbound.protection.outlook.com [40.107.15.50]) by sourceware.org (Postfix) with ESMTPS id 4A4053858D35 for <libc-alpha@sourceware.org>; Mon, 27 Jul 2020 09:27:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4A4053858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Szabolcs.Nagy@arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W/4RxwJ/dU3/JWiEdTzzC6pl1uSsJD/rvAbJk1VuaV4=; b=fE5+4dPYQ1vx3UPSzo+K4YXI4j4gnWt6RRzzNy7PVCjT4vjwYJovJJPYiE7x0ZAzD2Sgme5hinOc6iWRjSaxrfc1ze0gAQY2gAzUXtbZSMYqziGgRMzH9VM+mQAGlLB8wiAd2JtzP+tFI/Z45R1CIIRrWihYK/GRV9vTrk3Sm8A= Received: from MR2P264CA0022.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:1::34) by VI1PR0802MB2191.eurprd08.prod.outlook.com (2603:10a6:800:a1::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.28; Mon, 27 Jul 2020 09:27:03 +0000 Received: from VE1EUR03FT055.eop-EUR03.prod.protection.outlook.com (2603:10a6:500:1:cafe::9c) by MR2P264CA0022.outlook.office365.com (2603:10a6:500:1::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21 via Frontend Transport; Mon, 27 Jul 2020 09:27:03 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; sourceware.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; sourceware.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT055.mail.protection.outlook.com (10.152.19.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Mon, 27 Jul 2020 09:27:03 +0000 Received: ("Tessian outbound c4059ed8d7bf:v62"); Mon, 27 Jul 2020 09:27:03 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 4ee953b2b9198843 X-CR-MTA-TID: 64aa7808 Received: from 9aea371cad00.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 23357CCA-52F7-4673-8E37-8054846F7CAB.1; Mon, 27 Jul 2020 09:26:57 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 9aea371cad00.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 27 Jul 2020 09:26:57 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G1CJ1xiLf+1f0z0bRqex6Z14S3vGToRwl2rkXAa3jvhQ8HMtnRzfIMuysIffZRecNXCcagjl9zJG3NGQ4kS6sj5MoPLNPGtuon8IPbTmUm554pl616MswcSaMC073soRJHazDqyA1MbWeAW1uIVKEHm/IND49e0FmRGjsn5JWNPl9lzmiXe2bMXwtWO84b7qjzwkm7SUK+j5mi6S+Yht/PWvsS4m7h2Q/olQujn9xtOpofqSuZGz+m4lXvcI/Nkw73acZC2oBMbv9EvZ7J7yEgZaUr1q2I1hwP7quzOAVbBdc0bKjVUIRt+nrrACdB67Fc2Vhv29gucvnHVpwWBoyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W/4RxwJ/dU3/JWiEdTzzC6pl1uSsJD/rvAbJk1VuaV4=; b=ka2S1ua0yfKE8KjHqs+XnVoK7c8JVGo8XzvLPqongotJGzifab2u3FozHBnqxpJFZoIH5/KppWTstoIHgfcQr3MoerhDz5fFX8k7slsX6kLQ0xvqVqMoEkWNezGGq2Kwr/D2xVhhHfi04imSA7D35AWkcMLb+qH9OxLU7yJbOiGgng0bLO+/5IWS74ATXdKiC9IBtxdmsJ3t7CK5QQno8mmJCv4uODQcLTpFZ+LOwBVdxgGkjHpbqw1vTK/gIO55o7RYU1ZvgUX2XcRjKggEugx19kHilguVphc22uSzKTiFN+FpIrbnBkyKso3TBft4CiHrRZ3gVDCWByw+3qyzUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W/4RxwJ/dU3/JWiEdTzzC6pl1uSsJD/rvAbJk1VuaV4=; b=fE5+4dPYQ1vx3UPSzo+K4YXI4j4gnWt6RRzzNy7PVCjT4vjwYJovJJPYiE7x0ZAzD2Sgme5hinOc6iWRjSaxrfc1ze0gAQY2gAzUXtbZSMYqziGgRMzH9VM+mQAGlLB8wiAd2JtzP+tFI/Z45R1CIIRrWihYK/GRV9vTrk3Sm8A= Authentication-Results-Original: sourceware.org; dkim=none (message not signed) header.d=none;sourceware.org; dmarc=none action=none header.from=arm.com; Received: from AM6PR08MB3047.eurprd08.prod.outlook.com (2603:10a6:209:4c::23) by AM6PR08MB3832.eurprd08.prod.outlook.com (2603:10a6:20b:89::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Mon, 27 Jul 2020 09:26:56 +0000 Received: from AM6PR08MB3047.eurprd08.prod.outlook.com ([fe80::2404:de9f:78c0:313c]) by AM6PR08MB3047.eurprd08.prod.outlook.com ([fe80::2404:de9f:78c0:313c%6]) with mapi id 15.20.3216.033; Mon, 27 Jul 2020 09:26:56 +0000 From: Szabolcs Nagy <szabolcs.nagy@arm.com> To: libc-alpha@sourceware.org Subject: [PATCH] aarch64: Use future HWCAP2_MTE in ifunc resolver Date: Mon, 27 Jul 2020 10:26:49 +0100 Message-Id: <20200727092649.31740-1-szabolcs.nagy@arm.com> X-Mailer: git-send-email 2.17.1 Content-Type: text/plain X-ClientProxiedBy: LNXP265CA0049.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::13) To AM6PR08MB3047.eurprd08.prod.outlook.com (2603:10a6:209:4c::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost.localdomain (217.140.106.52) by LNXP265CA0049.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24 via Frontend Transport; Mon, 27 Jul 2020 09:26:55 +0000 X-Mailer: git-send-email 2.17.1 X-Originating-IP: [217.140.106.52] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 99dee5d6-8bfc-4355-6a06-08d8320f38d0 X-MS-TrafficTypeDiagnostic: AM6PR08MB3832:|VI1PR0802MB2191: X-Microsoft-Antispam-PRVS: <VI1PR0802MB2191B79EC7F95F64E64EB76CED720@VI1PR0802MB2191.eurprd08.prod.outlook.com> x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:4303;OLM:4303; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: K5f59TJDxiUs2LhZMWpsmMs9lKBPX/dKefu2vXZHplo5r7hQwkcjMqAYueMrsszbclJUqPWGXjSylxhKvfYWin7tgvPHdL/3/7J6gy5aHyQusYv1qq8KmCnXxkzER0OP5OK9+jPnoujBpMxoe3tJK/JChEswlYBJ762VT7aeadI4sUnj2imEUvSti8J84JI7sf4pX/YEDkJyCzmN3fULgXLh+ap6Q9vZuvHHQKNtK+6LXzqWbEp4zl7gmyOM37N5PBlvmcDLBnJo8Ry7MKiA2qZgGloz9Jp5fCiHq1vI9Q9EKywr13VOuQOYlzOhDiXSsX7gu3LtWwqhjBIVhFyurlIL6+Mq5Pr1H349DMJGOQkIXlrX4Cp0mylchJPzMKQswJmoQjR8JncM8nnXdfmBmEROqxj7ZPuOCXUOoHIJj+LGwq0yRvIR6WTxmfP78dE4UYQ2H6AO80XFrCou1BM3Dg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB3047.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(136003)(366004)(39860400002)(396003)(6916009)(956004)(6512007)(1076003)(316002)(8676002)(44832011)(86362001)(16526019)(186003)(2616005)(52116002)(6506007)(6486002)(26005)(6666004)(478600001)(2906002)(966005)(5660300002)(69590400007)(36756003)(4326008)(66556008)(66476007)(8936002)(66946007)(83380400001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: o6ON5c2S2ZKqQclh8DTF6Pr9g9PfPPZFMZIZ1i2HtDFRNArP9YDXUQUGG6I0AdbvclefqtUdR2r1fplE3y9p+i0n7gKjgQq4VlWOW/NEYO6JR80X5MG9D2ZWsuwKXICNywjXjfqLwSAgKPZobgExlyyOBcZpdog6bCLkMncRGfXgpQdchFTk+Dj0t7zKbgTzjCkq1jDK4Ie3ooc16aIfKCiouwWFhTxi6GRkOzJNZYv3Fi+OnJC5nJD2j1p/UFPRJPbHOMKOZ1nBR+ZjrrlfOfavAokMMMnyiiQURyfDDt5G6oXRmuKZrihtkktH7bNd3G+OKjxbpFBhgCKsfKRCrt46Bh870tEAuxOtOK/3tDkVEM1mmZns7m17as68eIYCIbfLSjAx5c0H0vGR5qqOu+xWymPeQ6BQ3mRoTuX0pmsaRM+zlw0p/G6ngLZNPWeyiksIrsAXXRxxYEx9uUW/SYvuJpG2FtsUOnCULqtx9NNAZz6zhvcA1qfLg4ukljYU X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3832 Original-Authentication-Results: sourceware.org; dkim=none (message not signed) header.d=none; sourceware.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT055.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: da3a9a67-1f92-49be-4163-08d8320f3468 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SyFwGRTgZwBnDGsYm050JMjdn/+AE22rSjqwcIlZf4gQwXcMcoWmJMcVXTsE57LtbY+klgEX1/x/oQ8ShKLKCS+rP2LfbI9vDLCY7GmLu4oIcacovYIDIcptnVBnxwPi9HI7/6WyOaozcsX6iG5q4KdAu0hqewcgDDZw/rENOcyWkt0okrUoNALqm53vAghrpk86gDyUIWWDuCqvYFfIeAWZnu0/qfn5VT+iqU3uYFIWwwyxZR/lIUTBPGukSMggKV/cKTLcsZ7ioZ0u32gdkrx/H5IPoanPVEAMkOPNUpbat3hj2/0rWDNBjaYnWbStVh74tJxXU//DcKKLpUl0UJ1iGtZTpdKPAIBdAHX3PjXaZ5kIKyj5aCYwk+zeHaMResQ846oLUIngDlP/RMcNcaeV/y2abbJHey4zCihiiNVBV1wtldKlIB3GYQahgkj59qByVQ6v/HGuupviPbAvVTMb3E/J3nKIanw3zPCKIvKbJLsFAmrTHTAUmoJJVuo8 X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(396003)(39860400002)(46966005)(70206006)(36756003)(70586007)(966005)(6506007)(26005)(86362001)(186003)(16526019)(2616005)(6486002)(5660300002)(956004)(44832011)(6666004)(1076003)(8676002)(6916009)(336012)(4326008)(316002)(36906005)(6512007)(8936002)(478600001)(83380400001)(2906002)(356005)(47076004)(82310400002)(69590400007)(107886003)(81166007)(82740400003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2020 09:27:03.0888 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 99dee5d6-8bfc-4355-6a06-08d8320f38d0 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT055.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2191 X-Spam-Status: No, score=-15.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, UNPARSEABLE_RELAY 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 <libc-alpha.sourceware.org> List-Unsubscribe: <http://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <http://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
aarch64: Use future HWCAP2_MTE in ifunc resolver
|
|
Commit Message
Szabolcs Nagy
July 27, 2020, 9:26 a.m. UTC
Make glibc MTE-safe on systems where MTE is available. This allows using heap tagging with an LD_PRELOADed malloc implementation that enables MTE. We don't document this as guaranteed contract yet, so glibc may not be MTE safe when HWCAP2_MTE is set (older glibcs certainly aren't). This is mainly for testing and debugging. The HWCAP flag is not exposed in public headers until Linux adds it to its uapi. The HWCAP value reservation will be in Linux 5.9. --- I'd like to commit this for 2.32, it is safe even if the hwcap value changes because there is no mte safety guarantee (but there is no reason for linux to change the value). linux commit: http://git.kernel.org/arm64/c/a46cec12f4a5 tested in qemu. --- sysdeps/aarch64/multiarch/strlen.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
Comments
* Szabolcs Nagy: > Make glibc MTE-safe on systems where MTE is available. This allows > using heap tagging with an LD_PRELOADed malloc implementation that > enables MTE. We don't document this as guaranteed contract yet, so > glibc may not be MTE safe when HWCAP2_MTE is set (older glibcs > certainly aren't). This is mainly for testing and debugging. > > The HWCAP flag is not exposed in public headers until Linux adds it > to its uapi. The HWCAP value reservation will be in Linux 5.9. It's not yet in Linus' tree, though? I think this is safe because the MTE code will run just fine on non-MTE systems (if the bit is repurposed after all), right? Thanks, Florian
The 07/27/2020 11:54, Florian Weimer wrote: > * Szabolcs Nagy: > > > Make glibc MTE-safe on systems where MTE is available. This allows > > using heap tagging with an LD_PRELOADed malloc implementation that > > enables MTE. We don't document this as guaranteed contract yet, so > > glibc may not be MTE safe when HWCAP2_MTE is set (older glibcs > > certainly aren't). This is mainly for testing and debugging. > > > > The HWCAP flag is not exposed in public headers until Linux adds it > > to its uapi. The HWCAP value reservation will be in Linux 5.9. > > It's not yet in Linus' tree, though? > > I think this is safe because the MTE code will run just fine on non-MTE > systems (if the bit is repurposed after all), right? yes.
* Szabolcs Nagy: > The 07/27/2020 11:54, Florian Weimer wrote: >> * Szabolcs Nagy: >> >> > Make glibc MTE-safe on systems where MTE is available. This allows >> > using heap tagging with an LD_PRELOADed malloc implementation that >> > enables MTE. We don't document this as guaranteed contract yet, so >> > glibc may not be MTE safe when HWCAP2_MTE is set (older glibcs >> > certainly aren't). This is mainly for testing and debugging. >> > >> > The HWCAP flag is not exposed in public headers until Linux adds it >> > to its uapi. The HWCAP value reservation will be in Linux 5.9. >> >> It's not yet in Linus' tree, though? >> >> I think this is safe because the MTE code will run just fine on non-MTE >> systems (if the bit is repurposed after all), right? > > yes. Okay, then this is fine for glibc 2.32. Thanks. Florian
On 27/07/2020 06:26, Szabolcs Nagy wrote: > Make glibc MTE-safe on systems where MTE is available. This allows > using heap tagging with an LD_PRELOADed malloc implementation that > enables MTE. We don't document this as guaranteed contract yet, so > glibc may not be MTE safe when HWCAP2_MTE is set (older glibcs > certainly aren't). This is mainly for testing and debugging. > > The HWCAP flag is not exposed in public headers until Linux adds it > to its uapi. The HWCAP value reservation will be in Linux 5.9. > > --- > I'd like to commit this for 2.32, it is safe even if the hwcap value > changes because there is no mte safety guarantee (but there is no > reason for linux to change the value). > > linux commit: > http://git.kernel.org/arm64/c/a46cec12f4a5 > > tested in qemu. > --- > sysdeps/aarch64/multiarch/strlen.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/sysdeps/aarch64/multiarch/strlen.c b/sysdeps/aarch64/multiarch/strlen.c > index 7c0352dd87..9440decf75 100644 > --- a/sysdeps/aarch64/multiarch/strlen.c > +++ b/sysdeps/aarch64/multiarch/strlen.c > @@ -26,8 +26,14 @@ > # include <string.h> > # include <init-arch.h> > > -/* This should check HWCAP_MTE when it is available. */ > -#define MTE_ENABLED() (false) > +/* This should check HWCAP2_MTE when it is available: current > + linux kernel does not expose it, but its value is reserved. > + This is needed to make glibc MTE-safe on future systems in > + case user code enables MTE. The ABI contract for enabling Double space after period. Besides it, the patch is ok. > + MTE is not yet specified, but it can be useful for at least > + debugging which does not need a contract. */ > +#define FUTURE_HWCAP2_MTE (1 << 18) > +#define MTE_ENABLED() (GLRO(dl_hwcap2) & FUTURE_HWCAP2_MTE) > > extern __typeof (__redirect_strlen) __strlen; > >
diff --git a/sysdeps/aarch64/multiarch/strlen.c b/sysdeps/aarch64/multiarch/strlen.c index 7c0352dd87..9440decf75 100644 --- a/sysdeps/aarch64/multiarch/strlen.c +++ b/sysdeps/aarch64/multiarch/strlen.c @@ -26,8 +26,14 @@ # include <string.h> # include <init-arch.h> -/* This should check HWCAP_MTE when it is available. */ -#define MTE_ENABLED() (false) +/* This should check HWCAP2_MTE when it is available: current + linux kernel does not expose it, but its value is reserved. + This is needed to make glibc MTE-safe on future systems in + case user code enables MTE. The ABI contract for enabling + MTE is not yet specified, but it can be useful for at least + debugging which does not need a contract. */ +#define FUTURE_HWCAP2_MTE (1 << 18) +#define MTE_ENABLED() (GLRO(dl_hwcap2) & FUTURE_HWCAP2_MTE) extern __typeof (__redirect_strlen) __strlen;