public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 0/9] Add UBSan to the build
Date: Thu, 30 Aug 2018 18:41:00 -0000	[thread overview]
Message-ID: <00b73eed-01eb-ff51-e81d-35b0d6ae75d9@redhat.com> (raw)
In-Reply-To: <87tvnevw5i.fsf@tromey.com>

On 08/29/2018 01:44 AM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> 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
<https://gcc.gnu.org/install/configure.html>:

"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

  reply	other threads:[~2018-08-30 18:41 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-27 14:57 Tom Tromey
2018-08-27 14:57 ` [PATCH 7/9] Avoid undefined behavior in ada_operator_length Tom Tromey
2018-08-27 14:57 ` [PATCH 3/9] Avoid undefined behavior in extract_integer Tom Tromey
2018-08-28 18:39   ` Pedro Alves
2018-08-29  0:11     ` Tom Tromey
2018-08-27 14:57 ` [PATCH 6/9] Avoid undefined behavior in read_signed_leb128 Tom Tromey
2018-08-27 14:57 ` [PATCH 2/9] Use unsigned as base type for some enums Tom Tromey
2018-08-27 19:22   ` Simon Marchi
2018-08-27 20:22     ` Tom Tromey
2018-08-27 21:26       ` Simon Marchi
2018-08-28 18:54         ` Pedro Alves
2018-08-28 22:42         ` Tom Tromey
2018-08-29  0:01           ` Tom Tromey
2018-08-27 14:57 ` [PATCH 5/9] Avoid undefined behavior in parse_number Tom Tromey
2018-08-27 14:57 ` [PATCH 1/9] Do not pass NULL to memcpy Tom Tromey
2018-08-27 19:12   ` Simon Marchi
2018-08-28 22:40     ` Tom Tromey
2018-08-27 14:59 ` [PATCH 4/9] Avoid undefined behavior in read_subrange_type Tom Tromey
2018-08-27 14:59 ` [PATCH 9/9] Add --enable-ubsan Tom Tromey
2018-08-27 14:59 ` [PATCH 8/9] Avoid undefined behavior in expression dumping Tom Tromey
2018-08-28 18:49   ` Pedro Alves
2018-08-29  0:27     ` Tom Tromey
2018-08-28 19:03 ` [PATCH 0/9] Add UBSan to the build Pedro Alves
2018-08-29  0:45   ` Tom Tromey
2018-08-30 18:41     ` Pedro Alves [this message]
2018-08-30 18:56       ` Tom Tromey
2018-08-30 19:06         ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=00b73eed-01eb-ff51-e81d-35b0d6ae75d9@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).