From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63950 invoked by alias); 30 Aug 2018 18:41:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 63936 invoked by uid 89); 30 Aug 2018 18:41:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Impact, devel X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Aug 2018 18:41:44 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8CF2E807A0D0; Thu, 30 Aug 2018 18:41:42 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1846B63F4A; Thu, 30 Aug 2018 18:41:41 +0000 (UTC) Subject: Re: [PATCH 0/9] Add UBSan to the build To: Tom Tromey References: <20180827145620.11055-1-tom@tromey.com> <152ef6ac-cd48-72be-6fae-9397bca2c8b8@redhat.com> <87tvnevw5i.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <00b73eed-01eb-ff51-e81d-35b0d6ae75d9@redhat.com> Date: Thu, 30 Aug 2018 18:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <87tvnevw5i.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-08/txt/msg00839.txt.bz2 On 08/29/2018 01:44 AM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> I think this is a good idea. On enabling this by default on devel > Pedro> builds, do you have a sense of CPU/memory overhead this introduces? > > I have no idea about the CPU. It doesn't seem notably slower to me but > I am not sure I would really notice. Here: https://developer.apple.com/documentation/code_diagnostics/undefined_behavior_sanitizer it says: " Performance Impact The performance impact of the Undefined Behavior Sanitizer is minimal, with with an average 20% CPU overhead in the Debug configuration. " 20% seems quite a bit. Might be noticeable in "make check" time. If you're doing performance analysis, say, running "make check-perf", or running some use case under "perf", sounds like you'll need to be sure to disable UBSan. I also mildly worry about random people comparing the performance of master GDB or some ftp snapshot against previous GDB versions or against other debuggers and being mislead. If that slowdown is true, I think we should at least document it somewhere more prominently, as I think that so far release vs development mode didn't have much of an impact? Kind of like how GCC documents --enable-checking, at : "When you specify this option, the compiler is built to perform internal consistency checks of the requested complexity. This does not change the generated code, but adds error checking within the compiler. This will slow down the compiler and may only work properly if you are building the compiler with GCC. This is ‘yes,extra’ by default when building from SVN or snapshots, but ‘release’ for releases." Thanks, Pedro Alves