From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 518 invoked by alias); 5 Sep 2018 12:11:34 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 405 invoked by uid 89); 5 Sep 2018 12:11:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:D*samsung.com, sk:get_sta X-HELO: EUR03-AM5-obe.outbound.protection.outlook.com Received: from mail-eopbgr30087.outbound.protection.outlook.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (40.107.3.87) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Sep 2018 12:11:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZCkC1meX7niZmnD2vUWcnjTBPMF+7Thw5ufxyEHoXhI=; b=erdxzrgK/4C1iPttFxsGF5w3WS85cvA7p2TWH2vXnBkvWsg7i1pomk0e0rFBakzqQNXYa0ziuPawoLxgwN3w1IPxHRWACMTglfgQmmP16/q9CBeW9EpIaFH5A1+1kNXq8d0FlnRAGjTvEOtaN5i0jfpHe2BMD/fcH+ywqsvlets= Received: from DB5PR08MB1030.eurprd08.prod.outlook.com (10.166.14.15) by DB5PR08MB1016.eurprd08.prod.outlook.com (10.166.14.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.18; Wed, 5 Sep 2018 12:11:28 +0000 Received: from DB5PR08MB1030.eurprd08.prod.outlook.com ([fe80::6136:7a10:5f2:7593]) by DB5PR08MB1030.eurprd08.prod.outlook.com ([fe80::6136:7a10:5f2:7593%3]) with mapi id 15.20.1101.016; Wed, 5 Sep 2018 12:11:28 +0000 From: Wilco Dijkstra To: Denis Khalikov , GCC Patches CC: "v.barinov@samsung.com" , nd Subject: Re: [PATCH] Frame pointer for arm with THUMB2 mode Date: Wed, 05 Sep 2018 12:11:00 -0000 Message-ID: References: ,<20180828104451eucas1p2f1de5376f7a84b71487d21f41b5fdbb5~PBnOkIagS0753307533eucas1p2n@eucas1p2.samsung.com> In-Reply-To: <20180828104451eucas1p2f1de5376f7a84b71487d21f41b5fdbb5~PBnOkIagS0753307533eucas1p2n@eucas1p2.samsung.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco.Dijkstra@arm.com; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SW-Source: 2018-09/txt/msg00295.txt.bz2 Hi Denis, > We are working on applying Address/LeakSanitizer for the full Tizen OS > distribution. It's about ~1000 packages, ASan/LSan runtime is installed=20 > to ld.so.preload. As we know ASan/LSan has interceptors for=20 > allocators/deallocators such as (malloc/realloc/calloc/free) and so on. > On every allocation from user space program, ASan calls > GET_STACK_TRACE_MALLOC; > which unwinds the stack frame, and by default uses frame based stack > unwinder. So, it requires to build with "-fno-omit-frame-pointer",=20 > switching it to default unwinder really hits the performance in our case. So this sounds like the first thing to do is reducing the size of the stack= traces. The default is 30 which is far larger than useful. Using 1 for example shou= ld always be fast (since you can use __builtin_return_address(0)) and still get the function that called malloc. Also if the unwinder happens to be too slo= w, it should be optimized and caching added etc. >> Doing real unwinding is also far more accurate than frame pointer based > > unwinding (the latter doesn't handle leaf functions correctly,=20 > entry/exit in > > non-leaf functions and shrinkwrapped functions - and this breaks=20 > callgraph > > profiling). > > I agree, but in our case, all interceptors for allocators are > leaf functions, so the frame based stack unwinder works well for us. Yes a frame chain would work for this case. But it's not currently supporte= d. > By default we build packages with ("-marm" "-fno-omit-frame-pointer"), > because need frame based stack unwinder for every allocation, as I said > before. As we know GCC sets fp to lr on the stack with=20 > ("-fno-omit-frame-pointer" and "-marm") and I don't really know why. > But the binary size is bigger than for thumb, so, we cannot use default=20 > thumb frame pointer and want to reduce binary size for the full=20 > sanitized image. The issue is that the frame pointer and frame chain always add a large overhead even when you do not use any sanitizers. This is especially bad for the proposed patch - you lose much of the benefit of using Thumb-2... Using normal unwinding means your code runs at full speed and still can be used by the sanitizer. > In other case clang works the same way, as I offered at the patch. > It has the same issue, but it was fixed at the end of 2017 > https://bugs.llvm.org/show_bug.cgi?id=3D18505 (The topics starts from > discussion about APCS, but it is not the main point.) > > Also, unresolved issue related to this > https://github.com/google/sanitizers/issues/640 Adding support for a frame chain would require an ABI change. It would have= to=20 work across GCC, LLVM, Arm, Thumb-1 and Thumb-2 - not a trivial amount of effort. Wilco