Message ID | AM0PR03MB488253CF19B1113D56777D3182BD9@AM0PR03MB4882.eurprd03.prod.outlook.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.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 B9421383A63D for <patchwork@sourceware.org>; Fri, 1 Jul 2022 12:40:46 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2117.outbound.protection.outlook.com [40.107.21.117]) by sourceware.org (Postfix) with ESMTPS id 3844D385B805 for <gcc-patches@gcc.gnu.org>; Fri, 1 Jul 2022 12:40:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3844D385B805 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=Syrmia.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Syrmia.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LlxZLQ/U6yPU7wctTJcoGJRKDRr6EIfc6WOA/09Xj4gPfHWPz0kBGvlhvP1ca2WE59irSmfF2lHPn7hRdvgOr63PHI2enyMctd110H28SN+EM2OcBf6X/ua6Qx3go2g0rb3RJ8KCwIOhGsYr51uDkcjBsDPDwW4cVe5deYr6TpJC2kUWf7zyJII3hdUp/NSFhqHjQ2HqsMLqizc3JpcvEIO9f4hJVa3u+/DCMSHMqSlo9bVF9f6qEMybBfSykZvfkwQ0mh45lqB4imYwIUpgs9X/2TXK0aIRKcyeXnHKVXBKYszvjL++ysay50N6bHfKPPqLMYqXKfkDNihv6Vks2g== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=58EPKM4Oz4ORPEejB9iOpwOOlOvTDWDgz1Jj3koKLRs=; b=AbISGilmD9t7ZoCH2nuiHRqbwoU1zJGb2n9VX/AgWuA+42Jbeu0v0H5V+dOz8ciujTz2oZE6CbbqJtl5jbwgdmvdxE3q9qA9AATUq6UPN+7eWvrrG1g00JOEZUhu8QDRtVkJrjlMpNmINzI0o263IfXaWEvonbRHmdps/30azK6U4VLI5p+UTENFBQshWbsnkGdczZNizGpSk6AiPBa3HFQDSIZPjQMuiDrVzbxQ6V1zsRATAXU4Z2BFbFYq15+CZF2PhpxePrZf6ED+ypI522EBJAdHCUl11yLxNzZbKhFH4dKt9aifd5PP7Eo/VPQIfw/xGlcph04/xzq+7a3Fsw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=syrmia.com; dmarc=pass action=none header.from=syrmia.com; dkim=pass header.d=syrmia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=syrmia.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=58EPKM4Oz4ORPEejB9iOpwOOlOvTDWDgz1Jj3koKLRs=; b=WjIC1CHC6vnMQgPCdhYYgF+b1dYhSnvKOuXkfxUOUpf+8ZFyRpO8VXdghhRtJ6g3vXFkoz3+6HD6+p+7XnW6XD4RFYSv5Bbgj9punl4p6qBQUn/IRWXcj1HjXte+JYyhpH8Av5TIzp+v2+zmAlxTD9IOR9XTe0/pLiMFuWJb//Y= Received: from AM0PR03MB4882.eurprd03.prod.outlook.com (2603:10a6:208:fb::17) by VI1PR03MB4991.eurprd03.prod.outlook.com (2603:10a6:803:be::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5395.14; Fri, 1 Jul 2022 12:40:26 +0000 Received: from AM0PR03MB4882.eurprd03.prod.outlook.com ([fe80::3926:6805:c765:27ec]) by AM0PR03MB4882.eurprd03.prod.outlook.com ([fe80::3926:6805:c765:27ec%7]) with mapi id 15.20.5395.015; Fri, 1 Jul 2022 12:40:26 +0000 From: Dimitrije Milosevic <Dimitrije.Milosevic@Syrmia.com> To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org> Subject: Mips: Fix kernel_stat structure size Thread-Topic: Mips: Fix kernel_stat structure size Thread-Index: AQHYjUL/Q7GnLzDA50urYJcPdtpP9w== Date: Fri, 1 Jul 2022 12:40:26 +0000 Message-ID: <AM0PR03MB488253CF19B1113D56777D3182BD9@AM0PR03MB4882.eurprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 7905740f-e002-9fb6-9ac9-62f5ecaad199 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=Syrmia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 979d3e6c-b73c-43e2-3b2e-08da5b5edfe2 x-ms-traffictypediagnostic: VI1PR03MB4991:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5LfdRIS7zFrT9VoQjVVjK2H7MnNCDgnW2OauxqCySYg2b2svF+WVG5FU9VjmmOJc6GRBRwVYMtmQAfMGAnwv8f1RPhlGWizd58KcDy/pCT/peb4AFaxX1OH6Kt2Bpxc6PsovCWCVYdodnvK3AikHDr/OQXSpT11UO69HoKBshZtRH8FZ0QoBEJdDRkqFH8YguAWDSeVQEhzjxRPcP5pQXooQV8k3Poqj4HcueeJhybDdDrBo1aZGxR7xfORFxmP6Yugq6H3oNVwT9De8R5qLV8COnNHijdySanBktslUaDej7pKwldpTMctdDY2VoeUYcNU0H302IpgKNgqKp5Koto23s9ZKlJVN3OHWo/oqxjuYACFvLIl3NzjzFZM2//kiwXFJJHx1NVDj1FjZcJeUULcsTOeBGr+Qqtuu6n1BpP2bxQdU/WdIbpaljS66LgvfRX8MKeDAMJs30vZKqcb13lcpOOxjAw3aNjqO+rszoJ9BH73r5pg4oubI6zlhVuGop4y+Og+bcUPkk6QSFCin9h5KZnF0+vqKRKnG4tZX/uQzewIAKPzUlOXtDBVX/b6SNENiExMduGezqoKHPXZ2b7fRByyl5zpRjTvJcafFsj2QW0wkpOUg2kZmtV9dTq+YyjRa5+4nAxQwj4A97bS5p682T3AVKgZTF9Nn/0BxeEko9OZzTNWTCnxz0DXhP5RoYZi93yFESh2h31mji21MjBWwjLLY1M0w1gTeSGC9MUNYV9Bi0OyCfPAvFb8MrRDOwfSXdIAW62y/9DYwzmx9PJxO1sWzKlh+nOF2Qy1KppG9oiLi6hWSsIvxxK4DVb+a x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR03MB4882.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(366004)(376002)(39830400003)(346002)(136003)(396003)(6506007)(7696005)(122000001)(55016003)(8936002)(52536014)(6916009)(316002)(54906003)(9686003)(86362001)(38100700002)(64756008)(76116006)(2906002)(66946007)(5660300002)(33656002)(66556008)(186003)(38070700005)(41300700001)(66446008)(66476007)(478600001)(71200400001)(4326008)(8676002)(91956017)(83380400001)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?q?qc2WT5hIJIpnpdTlPMz7suB?= =?iso-8859-1?q?DzF7SRZ4mnchPrF9mosrLaOF0ArQZqS+ozcx/1JYEme8NBAz9a8wn+uSAKoP?= =?iso-8859-1?q?Sr2aS8KpK68dPmqAYL3N9bBFEGkpCcfD0iXg/Bt9hkDGG/hVh9JLEZmRDOBg?= =?iso-8859-1?q?wsLZc+r35pwLdPuuHGoI4rVk5giB2lmww0wo6O9pbkXf2UZ2mwIADYSBCE/T?= =?iso-8859-1?q?Uy5IPYawMDx59pppD3bY3sTojlNfxHoLRtYXUd7YAZ+GsU4hwDYQoegqxFJZ?= =?iso-8859-1?q?fBFLit9X8K1IIhWpCwpow1duM/JXHrIyDHCi10yyxl0Ywf+cS6u6G/STYPVY?= =?iso-8859-1?q?X1ShK2xhRHngtqCul6vlW7OYYYeJdSnz7UpBMmp3I7YEeeMXI3cLkFujk+U/?= =?iso-8859-1?q?u0jm4AWXS+B6aIePn9f/zjtVF9Lyu0fbQ+0jyJ3DuR6GOEBpNmrpAxKMQDKW?= =?iso-8859-1?q?mXz+Pblq5XJ5Tw+sSO/slnOfQvqv+s11TOoI/Dvtkj0TkA0LTPX2YR8rhd9v?= =?iso-8859-1?q?oManXHGZvGHfzVH95w2Zl3gzrK9WuqhzecyAkRSNM2PJEjpPepxPqP0HK/aR?= =?iso-8859-1?q?LVjocNLX0EzJlHU66AocOykr2gMHmLxs2tl8kJqLz1rFCOtq8HfqPynzr+CJ?= =?iso-8859-1?q?SP3+3ezYCu+1O7QAa2SG55SeEM243x1mOEhVD07T7jrfaomOGH/JkpXikRBM?= =?iso-8859-1?q?vnSNW+an1q1hBVNqfWsqXqG6+h0aEyPxmwqIyoJkwdGFmelD8W1lD5S+KxX+?= =?iso-8859-1?q?xySnbXm5kLM0i+0WG438c62V6S8phAp0Tzfj96TnKRvcdnGrPbusAT3T2obj?= =?iso-8859-1?q?+8SsFF962rL0RzoGtwkU4TacMzej4q1/fbz57sXjBsSI+9zk+NxELd226uzk?= =?iso-8859-1?q?4R5cJ284woeb1oODq3L52nfi9IDHv1ywI3JVlbSmDYNYcf3Do2D1XA295p3B?= =?iso-8859-1?q?7oR32wxrvssLKQoxkbyZkwEgS2Opy4NC0BxoCrwmii1/R3BmGuYHfMQly3BV?= =?iso-8859-1?q?5M3Fs/9OobfE2CQFOqroefzPCkiNl/0ya87aVfxeDKE7glbIfHjbhqsCm9mc?= =?iso-8859-1?q?KFQSYnGBX8UOESL7qv4+ozQIgqeX0B7EnARaDYwno9mqMTuYSPIilPzqwkjO?= =?iso-8859-1?q?nrV2BT96zMTPuPyyWwkrN5ixnV2Pc/t4w9b04HZBDOe4zpcsf1gxWhCXIUVF?= =?iso-8859-1?q?d9pAxKnXlHDimGEF5lllI3ZKzdqsnE1yhGx08zuxXAXIvukU+1di0uQ8jaPj?= =?iso-8859-1?q?cQhjFJvuT7Y4R03NpHXi+dXCsk1bmTGf5QxnCZ0RUiQi8edtIg7u8IOHjAlh?= =?iso-8859-1?q?4ry/Nmowj3BNE6Xut51H3X9b79yQLoDsYS+z/0IODbgSDlv4t2KyE/ga8gLQ?= =?iso-8859-1?q?nkMbN+A1iKa9VSaNLsYVHrKbYOOvPrKDoexBwKKeXKGCcbIrtni+p9mRRr30?= =?iso-8859-1?q?PGmckOJSwMBGTDv02ITTUHltjKO/3Dbvl2jcqrpBtX1ycredr5EQZKUbBFMs?= =?iso-8859-1?q?qZXYXYekuAOggTuGJ7Zr/Mea9Zrc2I/j9m4skvJfjJiqwyRYFveBdfE7vn9P?= =?iso-8859-1?q?ClxdqckxdnX37l4R5OhX5j86pQDDtq3Lf+nMcMFVLdvphTaZi3ljP9d6HIEV?= =?iso-8859-1?q?goz+kLlrhMpgyyQ2ksfzewArCYMC8ou49mK1tWw=3D=3D?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: syrmia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB4882.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 979d3e6c-b73c-43e2-3b2e-08da5b5edfe2 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2022 12:40:26.7076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 19214a73-c1ab-4e19-8f59-14bdcb09a66e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U4IFasgXXxnE1dRL9RNkw6gLa2DyPjUZcJ3Sb4xpNUHhnAqGDqXge1B/YT5E20ILPaLQwzLOAymI3yt9RLP7O79iXYh6PikaSb0DNAhhc2s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4991 X-Spam-Status: No, score=-13.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Cc: Djordje Todorovic <Djordje.Todorovic@syrmia.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
Mips: Fix kernel_stat structure size
|
|
Commit Message
Dimitrije Milošević
July 1, 2022, 12:40 p.m. UTC
Fix kernel_stat structure size for non-Android 32-bit Mips. LLVM currently has this value for the kernel_stat structure size, as per compiler-rt/lib/sanitizer-common/sanitizer_platform_limits_posix.h. This also resolves one of the build issues for non-Android 32-bit Mips. libsanitizer/ChangeLog: * sanitizer_common/sanitizer_platform_limits_posix.h: Fix kernel_stat structure size for non-Android 32-bit Mips. --- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ---
Comments
On Fri, 2022-07-01 at 12:40 +0000, Dimitrije Milosevic wrote: > Fix kernel_stat structure size for non-Android 32-bit Mips. > LLVM currently has this value for the kernel_stat structure size, > as per compiler-rt/lib/sanitizer-common/sanitizer_platform_limits_posix.h. > This also resolves one of the build issues for non-Android 32-bit Mips. nit: the ChangeLog file name shall have no indents in the commit message, and there should be one tab (instead of 8 whitespaces) before the content. Like: libsanitizer/ChangeLog: * sanitizer_common/sanitizer_platform_limits_posix.h: Fix kernel_stat structure size for non-Android 32-bit Mips. Patch content LGTM as it just changes our code to match the upstream, but I don't have privilege to approve the change. Richard? > libsanitizer/ChangeLog: > > * sanitizer_common/sanitizer_platform_limits_posix.h: Fix > kernel_stat structure size for non-Android 32-bit Mips. > > --- > > libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h > index 89772a7e5c0..62a99035db3 100644 > --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h > +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h > @@ -83,7 +83,7 @@ const unsigned struct_kernel_stat64_sz = 104; > #elif defined(__mips__) > const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID > ? FIRST_32_SECOND_64(104, 128) > - : FIRST_32_SECOND_64(144, 216); > + : FIRST_32_SECOND_64(160, 216); > const unsigned struct_kernel_stat64_sz = 104; > #elif defined(__s390__) && !defined(__s390x__) > const unsigned struct_kernel_stat_sz = 64; > > ---
Thanks Xi. Forgive me as I'm not that familiar with the coding standards when submitting patches for a review. Here is the updated version of the patch. Fix kernel_stat structure size for non-Android 32-bit Mips. LLVM currently has this value for the kernel_stat structure size, as per compiler-rt/lib/sanitizer-common/sanitizer_platform_limits_posix.h. This also resolves one of the build issues for non-Android 32-bit Mips. libsanitizer/ChangeLog: * sanitizer_common/sanitizer_platform_limits_posix.h: Fix kernel_stat structure size for non-Android 32-bit Mips. --- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h index 89772a7e5c0..62a99035db3 100644 --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h @@ -83,7 +83,7 @@ const unsigned struct_kernel_stat64_sz = 104; #elif defined(__mips__) const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID ? FIRST_32_SECOND_64(104, 128) - : FIRST_32_SECOND_64(144, 216); + : FIRST_32_SECOND_64(160, 216); const unsigned struct_kernel_stat64_sz = 104; #elif defined(__s390__) && !defined(__s390x__) const unsigned struct_kernel_stat_sz = 64; ---
Ping. :)
I think this is good to go. Unfortunately, I do not have commit access, so if anyone
can commit it, that would be great!
From: Dimitrije Milosevic <Dimitrije.Milosevic@Syrmia.com>
Sent: Friday, July 1, 2022 4:25 PM
To: Xi Ruoyao <xry111@xry111.site>; gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org>
Cc: Djordje Todorovic <Djordje.Todorovic@syrmia.com>; Richard Sandiford <richard.sandiford@arm.com>
Subject: Re: Mips: Fix kernel_stat structure size
Thanks Xi. Forgive me as I'm not that familiar with the coding standards
when submitting patches for a review.
Here is the updated version of the patch.
Fix kernel_stat structure size for non-Android 32-bit Mips.
LLVM currently has this value for the kernel_stat structure size,
as per compiler-rt/lib/sanitizer-common/sanitizer_platform_limits_posix.h.
This also resolves one of the build issues for non-Android 32-bit Mips.
libsanitizer/ChangeLog:
* sanitizer_common/sanitizer_platform_limits_posix.h: Fix
kernel_stat structure size for non-Android 32-bit Mips.
---
libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 89772a7e5c0..62a99035db3 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -83,7 +83,7 @@ const unsigned struct_kernel_stat64_sz = 104;
#elif defined(__mips__)
const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID
? FIRST_32_SECOND_64(104, 128)
- : FIRST_32_SECOND_64(144, 216);
+ : FIRST_32_SECOND_64(160, 216);
const unsigned struct_kernel_stat64_sz = 104;
#elif defined(__s390__) && !defined(__s390x__)
const unsigned struct_kernel_stat_sz = 64;
---
On Fri, 1 Jul 2022, Dimitrije Milosevic wrote: > Fix kernel_stat structure size for non-Android 32-bit Mips. > LLVM currently has this value for the kernel_stat structure size, > as per compiler-rt/lib/sanitizer-common/sanitizer_platform_limits_posix.h. > This also resolves one of the build issues for non-Android 32-bit Mips. I insist that PR105614 comment #7 is the way to go, i.e. fix the merge error, avoiding the faulty include that it reintroduced. Was this tested on O32? > > libsanitizer/ChangeLog: > > * sanitizer_common/sanitizer_platform_limits_posix.h: Fix > kernel_stat structure size for non-Android 32-bit Mips. > > --- > > libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h > index 89772a7e5c0..62a99035db3 100644 > --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h > +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h > @@ -83,7 +83,7 @@ const unsigned struct_kernel_stat64_sz = 104; > #elif defined(__mips__) > const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID > ? FIRST_32_SECOND_64(104, 128) > - : FIRST_32_SECOND_64(144, 216); > + : FIRST_32_SECOND_64(160, 216); > const unsigned struct_kernel_stat64_sz = 104; > #elif defined(__s390__) && !defined(__s390x__) > const unsigned struct_kernel_stat_sz = 64; > > ---
On Fri, 2022-07-08 at 21:42 -0400, Hans-Peter Nilsson wrote: > On Fri, 1 Jul 2022, Dimitrije Milosevic wrote: > > > Fix kernel_stat structure size for non-Android 32-bit Mips. > > LLVM currently has this value for the kernel_stat structure size, > > as per compiler-rt/lib/sanitizer- > > common/sanitizer_platform_limits_posix.h. > > This also resolves one of the build issues for non-Android 32-bit > > Mips. > > I insist that PR105614 comment #7 is the way to go, i.e. fix > the merge error, avoiding the faulty include that it > reintroduced. Was this tested on O32? I'm pretty sure it is *not* the way to go. Sanitizer does not really intercept system call. It intercepts libc stat() or lstat() etc. calls. So you need to keep struct_kernel_stat_sz same as the size of struct stat in libc, i. e. "the size of buffer which *libc* stat()-like functions writing into". The "kernel_" in the name is just misleading. And, if you still think it should be the way to go, let's submit the change to LLVM and get it reviewed properly.
On Sat, 9 Jul 2022, Xi Ruoyao wrote: > On Fri, 2022-07-08 at 21:42 -0400, Hans-Peter Nilsson wrote: > > On Fri, 1 Jul 2022, Dimitrije Milosevic wrote: > > > > > Fix kernel_stat structure size for non-Android 32-bit Mips. > > > LLVM currently has this value for the kernel_stat structure size, > > > as per compiler-rt/lib/sanitizer- > > > common/sanitizer_platform_limits_posix.h. > > > This also resolves one of the build issues for non-Android 32-bit > > > Mips. > > > > I insist that PR105614 comment #7 is the way to go, i.e. fix > > the merge error, avoiding the faulty include that it > > reintroduced.? Was this tested on O32? > > I'm pretty sure it is *not* the way to go. > > Sanitizer does not really intercept system call. It intercepts libc > stat() or lstat() etc. calls. So you need to keep struct_kernel_stat_sz > same as the size of struct stat in libc, i. e. "the size of buffer which > *libc* stat()-like functions writing into". > > The "kernel_" in the name is just misleading. You make a sound argument, and I just refer to my old commit 9f943b2446f2d0a. Either way, the proof is in the pussing: was this tested for O32 or not? > And, if you still think it should be the way to go, let's submit the > change to LLVM and get it reviewed properly. Sorry, I've no longer interest in mips besides I'd like to see un-broken what I helped getting in a working state (support ASAN in gcc for mips O32). brgds, H-P
Hi Hans-Peter, You're right, this is not ok for the O32 ABI. Your change however, broke the functionality for the N32 ABI. AFAIK, the changes like this should go through LLVM first (yours didn't), so I will send out a review, covering both 32 ABIs, meaning that both O32 and N32 ABIs will be working properly. As for this change, I'm not sure what should be done? Should this be committed now, while the LLVM change is cherry-picked once it's committed. Best regards, Dimitrije Milosevic From: Hans-Peter Nilsson <hp@bitrange.com> Sent: Saturday, July 9, 2022 4:44 PM To: Xi Ruoyao <xry111@xry111.site> Cc: Dimitrije Milosevic <Dimitrije.Milosevic@Syrmia.com>; Djordje Todorovic <Djordje.Todorovic@syrmia.com>; gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org> Subject: Re: Mips: Fix kernel_stat structure size On Sat, 9 Jul 2022, Xi Ruoyao wrote: > On Fri, 2022-07-08 at 21:42 -0400, Hans-Peter Nilsson wrote: > > On Fri, 1 Jul 2022, Dimitrije Milosevic wrote: > > > > > Fix kernel_stat structure size for non-Android 32-bit Mips. > > > LLVM currently has this value for the kernel_stat structure size, > > > as per compiler-rt/lib/sanitizer- > > > common/sanitizer_platform_limits_posix.h. > > > This also resolves one of the build issues for non-Android 32-bit > > > Mips. > > > > I insist that PR105614 comment #7 is the way to go, i.e. fix > > the merge error, avoiding the faulty include that it > > reintroduced.? Was this tested on O32? > > I'm pretty sure it is *not* the way to go. > > Sanitizer does not really intercept system call. It intercepts libc > stat() or lstat() etc. calls. So you need to keep struct_kernel_stat_sz > same as the size of struct stat in libc, i. e. "the size of buffer which > *libc* stat()-like functions writing into". > > The "kernel_" in the name is just misleading. You make a sound argument, and I just refer to my old commit 9f943b2446f2d0a. Either way, the proof is in the pussing: was this tested for O32 or not? > And, if you still think it should be the way to go, let's submit the > change to LLVM and get it reviewed properly. Sorry, I've no longer interest in mips besides I'd like to see un-broken what I helped getting in a working state (support ASAN in gcc for mips O32). brgds, H-P
On Tue, 12 Jul 2022, Dimitrije Milosevic wrote: > Hi Hans-Peter, > You're right, this is not ok for the O32 ABI. Your change however, broke the functionality > for the N32 ABI. That's just not true. There was no mips support for ASAN in gcc, hence nothing to break for N32. Maybe an anachronism? Or maybe you mean plain backporting to LLVM? Perhaps it needs adjustments for their _FILE_OFFSET_BITS=64 builds? On the other hand, that struct_kernel_stat_sz shouldn't be affected by that - unless that's a misnomer or they get the includes wrong - but then again, the include part was fixed by the patch. Unless mis-merged, as in gcc currently. > AFAIK, the changes like this should go through LLVM first > (yours didn't), As I recall, and judging from the mentioned commit, this would have given them no benefit; no visible error to fix, as they're always building the runtime with for 64-bit file size. But yes, it should have been submitted there eventually. > so I will send out a review, covering both 32 ABIs, meaning that both O32 and N32 ABIs > will be working properly. Very good. Thank you in advance. > As for this change, I'm not sure what should be done? > Should this be committed now, while the LLVM change is cherry-picked once it's committed. > Best regards, > Dimitrije Milosevic > > > From: Hans-Peter Nilsson <hp@bitrange.com> > Sent: Saturday, July 9, 2022 4:44 PM > To: Xi Ruoyao <xry111@xry111.site> > Cc: Dimitrije Milosevic <Dimitrije.Milosevic@Syrmia.com>; Djordje Todorovic <Djordje.Todorovic@syrmia.com>; gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org> > Subject: Re: Mips: Fix kernel_stat structure size > ? > On Sat, 9 Jul 2022, Xi Ruoyao wrote: > > > On Fri, 2022-07-08 at 21:42 -0400, Hans-Peter Nilsson wrote: > > > On Fri, 1 Jul 2022, Dimitrije Milosevic wrote: > > > > > > > Fix kernel_stat structure size for non-Android 32-bit Mips. > > > > LLVM currently has this value for the kernel_stat structure size, > > > > as per compiler-rt/lib/sanitizer- > > > > common/sanitizer_platform_limits_posix.h. > > > > This also resolves one of the build issues for non-Android 32-bit > > > > Mips. > > > > > > I insist that PR105614 comment #7 is the way to go, i.e. fix > > > the merge error, avoiding the faulty include that it > > > reintroduced.? Was this tested on O32? > > > > I'm pretty sure it is *not* the way to go. > > > > Sanitizer does not really intercept system call.? It intercepts libc > > stat() or lstat() etc. calls.? So you need to keep struct_kernel_stat_sz > > same as the size of struct stat in libc, i. e. "the size of buffer which > > *libc* stat()-like functions writing into". > > > > The "kernel_" in the name is just misleading. > > You make a sound argument, and I just refer to my old commit > 9f943b2446f2d0a.? Either way, the proof is in the pussing: was > this tested for O32 or not? > > > And, if you still think it should be the way to go, let's submit the > > change to LLVM and get it reviewed properly. > > Sorry, I've no longer interest in mips besides I'd like to see > un-broken what I helped getting in a working state (support ASAN > in gcc for mips O32). > > brgds, H-P
On Tue, 2022-07-12 at 06:42 +0000, Dimitrije Milosevic wrote: > Hi Hans-Peter, > You're right, this is not ok for the O32 ABI. Your change however, broke the functionality > for the N32 ABI. AFAIK, the changes like this should go through LLVM first (yours didn't), > so I will send out a review, covering both 32 ABIs, meaning that both O32 and N32 ABIs > will be working properly. As for this change, I'm not sure what should be done? > Should this be committed now, while the LLVM change is cherry-picked once it's committed. I think just get it into LLVM first, then we sync with LLVM. It seems on o32 sizeof(struct stat) is 144, n32 -> 160, n64 -> 216 (tested on gcc23.fsffrance.org). "Luckily" we don't support other strange things like "o64".
On Tue, 2022-07-12 at 06:42 +0000, Dimitrije Milosevic wrote: > I will send out a review, covering both 32 ABIs, meaning that both O32 > and N32 ABIs will be working properly. Please CC me (@xry111) in LLVM review. By the way, if you have some spare time, you can also add the value for Musl (all 3 ABIs). Musl has a different struct stat than Glibc (it's PR 106136 in GCC bugzilla).
Hi Xi, > Please CC me (@xry111) in LLVM review. I just posted the patch. You should've gotten the email. If not, see: https://reviews.llvm.org/D129749. > By the way, if you have some spare time, you can also add the value for > Musl (all 3 ABIs). Musl has a different struct stat than Glibc (it's PR > 106136 in GCC bugzilla). I might be able to, but no promises. :) From: Xi Ruoyao <xry111@xry111.site> Sent: Wednesday, July 13, 2022 4:38 AM To: Dimitrije Milosevic <Dimitrije.Milosevic@Syrmia.com>; Hans-Peter Nilsson <hp@bitrange.com> Cc: Djordje Todorovic <Djordje.Todorovic@syrmia.com>; gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org> Subject: Re: Mips: Fix kernel_stat structure size On Tue, 2022-07-12 at 06:42 +0000, Dimitrije Milosevic wrote: > I will send out a review, covering both 32 ABIs, meaning that both O32 > and N32 ABIs will be working properly. Please CC me (@xry111) in LLVM review. By the way, if you have some spare time, you can also add the value for Musl (all 3 ABIs). Musl has a different struct stat than Glibc (it's PR 106136 in GCC bugzilla).
diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h index 89772a7e5c0..62a99035db3 100644 --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h @@ -83,7 +83,7 @@ const unsigned struct_kernel_stat64_sz = 104; #elif defined(__mips__) const unsigned struct_kernel_stat_sz = SANITIZER_ANDROID ? FIRST_32_SECOND_64(104, 128) - : FIRST_32_SECOND_64(144, 216); + : FIRST_32_SECOND_64(160, 216); const unsigned struct_kernel_stat64_sz = 104; #elif defined(__s390__) && !defined(__s390x__) const unsigned struct_kernel_stat_sz = 64;