From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12olkn2090.outbound.protection.outlook.com [40.92.22.90]) by sourceware.org (Postfix) with ESMTPS id 8F3D73858C2C for ; Thu, 18 Nov 2021 09:12:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8F3D73858C2C ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OqyVldRot24X3JfQX/uCKFR4wKrP+V9m1o29ZJaput44D/mr4VNOnDnjnsSBXucX1P/576rGfyDc5ZB3pBhi+BBkwOV1SwtZ0gx74Gw1AzH+wfHI929SNJwu8nYyfAueeV6MYObSuteB/iwJgXZPN1DQe+A1Dyi7oxY1lohf707E4iNl77HB+GwsZlhVh1ID/5Xzdfd+0ggbRWG2jG4TZkDhS2B+dOUo1edaznFW818TF2Xc/u+WmwfFa2Pbq2cfAvf2CcEHinb66uUcdR4XMZ0n4dx8c6G8lCN7jtSZibx+jSOkOuuG8daNhrCBxuZ2lr4tnlAeEIOcNp/Gk9cXTQ== 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=hjAcIZX07Rz8vNAhaejbuIjm/dLt2Nt7h29fzXCpnQI=; b=evBJ1hKrVtm3hKBB5tqBtdcz+fHglz7s2IP4JVo1VvFd1fDmYQOoIY5Ze+pqiqLH47XnirqQWjx4QRuuFnSsGOYXLGKD08nlYgPhl0sxKMrnfzS8oU2eMANozyrQqMTPAMCf+wHbeyI+uqmiIqxX2hv6stfUPdh8NCPiHI3s4q+pnmDqo7dXna0o0+Jm4qozBpWo5hQd1ofH5xhUilze2HFj7ClmPnfB+1CD3atc/6Q8Vw55EB8AJ4JI97Le3VCYUqiJscUY58TzmA5eUxzEM9etxKIfSZVE/2wpUxE2Aqt6moolQVstv+cqH+CCF/t/Hl+xMjBg6JNNgmdx7+J95g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DM6PR05MB4697.namprd05.prod.outlook.com (2603:10b6:5:18::13) by DM6PR05MB4476.namprd05.prod.outlook.com (2603:10b6:5:9e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.18; Thu, 18 Nov 2021 09:12:45 +0000 Received: from DM6PR05MB4697.namprd05.prod.outlook.com ([fe80::6016:ca1f:fa69:7100]) by DM6PR05MB4697.namprd05.prod.outlook.com ([fe80::6016:ca1f:fa69:7100%3]) with mapi id 15.20.4713.019; Thu, 18 Nov 2021 09:12:45 +0000 From: unlvsur unlvsur To: Jonathan Wakely , unlvsur unlvsur via Libstdc++ Subject: RE: putting __glibcxx_assert_fail into debug.cc bloats binary size by introducing all the dead code with debug.cc Thread-Topic: putting __glibcxx_assert_fail into debug.cc bloats binary size by introducing all the dead code with debug.cc Thread-Index: AQHX3Cp78LEWhsvoaUS2Xeic+vz6FKwI/40AgAAAjK0= Date: Thu, 18 Nov 2021 09:12:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [hEi6Qo9oTAAdRYKP0oUQNHh2n3vIF4RHkIDd5Su1c20dl8jb7tAUVmrdOF5VAtDhF3BySgeoxWg=] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: edf11134-8854-4f3b-a9d2-08d9aa739548 x-ms-traffictypediagnostic: DM6PR05MB4476: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SGxfwRAwQdDvqPmvjZ0cCkhyDtedtZtbXgjiYzpFgv7TLVkilAHykhXyyBxtCqKgkVdqD+p6a4RBKURJnWAbg9N6YYVv9LH2/Ik2+A05VsXmn13hF32UuByzHS2mNpU9QaRYL0mP+KzfjioWjO3R+2jPEXveYSCFU0FUc+NdPQbi1a5aXjn2Bq6myp58HB6OGQKNcWET8COHx7tpvptTbhXKEGKyZNzS1wG7l+QioPYxf/Ix2fGYf4cQ5ggzWoImjZn0lmcJFg4Kz1384kMuFdlRXu5Yuk4/iM7Kf0mf4TE/sl5dY5v+zFhyxm4ysCfpClyoT17kH/rjsrjU7KZ8dGAJtW0gDkc2mFXssZY2VbFTagtWOX4VAae2gxDx21I8N7RYiK+PjpLSIRsPV17koNADDg87SpX6n/Oc7rhZEqxKYQmiIgHiTm4Q/UlceFVGDaNCMsFTTWmc1CFtzv2LFwsHdMiE2bZT7055wfIziHOQGjumWyBAzW01i88EjYdBFhdNsGDtflpJt9LnevPhdEGnPMh4YIxENZJHOPZN1UhoOo6BnafeJ0n5jgWN2Z7OyyJPTwdLST69ozCEaNC6uQ== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: Wb951j40WXXD6oVKFX6j2LUkZCLC+Grh+b5CvRttXLIwO4IlwtN8L1CVAVZbfKJXPjsh2pFCc06tNaXmvt7BpPojcB/zLjeHj0tBpV1FPEMVigY/JF4bY5Bao7VOLigOitWfel6SoTRGaQtE5vQHtjhjjUpSRLWj52HCHyqZdzA/0TFsHejV/Y/KT5+NmgthD/Pl+77oCiLGyoyQqhlV22EhSDlAMU2CSIRK0VNeQNvgetRZaPaCeuMUDouPVkRsLAO8/bgwPdZmCdyu3wvN+DNQ5L6ik0OaDXoE64NZFk57rr//4f9MUc72JAX2tLA2JNtX4EZ7zRCn5V3LjqCrnxgAi2rhfH/a+Wk9bcbbbfIZxEOrUc1inSDHfd122G+V+q+uCXpHNn84+NQCKpqgE3lYu2ME0UBXihbAnx+3NnBi/EV9Pq6TtraMuDNtlCEO1w6AgWPOHfoRlkVD+Dv0kxAvAQpDIP1R5CAYi78OyFjoP5gnyXH9VHwZJOI62ZYhI0nPEz9OVHtc3aaxByq1vKgVepWiBO5PDFMYdHngiUzdPGrLZuy80Oy9S4ErJQpFBdIJK0rEhNKk9Xzs+vc8dBqGwSm04xrrFwe8DQ9TUSBYuLev4HL2h90Tngew/u2OSuoPOrZkT6S+YOlnV9UHQ3OwdVyK/VjD+BLFp38E39etbyv5AlE9o24aOJLP8SHs596/hJYJSAa9ZFXXO+vfHVlubgMMXixvpBpVdng+lqBcsdM+CJwuNu3Qwx8cVBAF/q6Ca44Q5SywxBpsFT3fdg== MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-3174-8-msonline-outlook-e6bda.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB4697.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: edf11134-8854-4f3b-a9d2-08d9aa739548 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2021 09:12:45.1664 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4476 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2021 09:12:48 -0000 There are all sorts of reasons why it does not work. sec18-quach.pdf (usenix.org) In the security paper Debloating Software through Piece-Wise Compilation an= d Loading Unused Functions. Static analysis during compilation can efficiently remove= dead code at a basic block level, however, entire unused functions are not eliminated. Consider the following= program: int f() { return 1; } int main() { return 0; } Both gcc and clang retain the function f in the above code even under optimization level -O3. Removal of unused functions require additional non-standard often-unus= ed compiler (-fdata-sections -ffunction-sections -Os) and linker (-Wl,--gc-= sections) optimization flags. Even so, unused functions in dynamically loaded libraries can not be elimin= ated during compile time. Sent from Mail for Window= s From: Jonathan Wakely Sent: Thursday, November 18, 2021 04:09 To: unlvsur unlvsur Cc: unlvsur unlvsur via Libstdc++ Subject: Re: putting __glibcxx_assert_fail into debug.cc bloats binary size= by introducing all the dead code with debug.cc On Thu, 18 Nov 2021, 03:16 unlvsur unlvsur via Libstdc++, > wrote: Can we put it into a separate translation unit with only __glibcxx_assert_f= ail? Linker does not remove dead functions. Why does -ffunction-sections not help?