unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: agrambot@gmail.com, emacs-devel@gnu.org
Subject: Re: Errors building from master with a clean repository
Date: Mon, 22 Apr 2019 17:31:44 -0700	[thread overview]
Message-ID: <84279731-9572-de3c-4806-a7c52fb79fee@cs.ucla.edu> (raw)
In-Reply-To: <83a7gi8ovg.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On 4/22/19 12:45 AM, Eli Zaretskii wrote:
>
> You have consistently removed the references to -gdwarf-N compiler
> option, presumably on the assumption that GCC nowadays automatically
> uses the highest supported version?

No, I was merely assuming that -gdwarf-4 is good enough to debug Emacs;
-gdwarf-5 is still marked as "experimental" in GCC 8's doc, and I
haven't used -gdwarf-5. If there's a significant advantage to using
-gdwarf-5 then discussion of it should be added to etc/DEBUG. In the
meantime I tried to improve the wording about this, in the attached patch.


> I think this section could greatly benefit from a short explanation
> what "undefined behavior" means, or a couple of examples of it.

It's hard to be brief as -fsanitize=undefined is a bit tricky, but I
took a shot at it by installing the attached.


[-- Attachment #2: 0001-Improve-UBSan-discussion-in-etc-DEBUG.patch --]
[-- Type: text/x-patch, Size: 3809 bytes --]

From afaab7395ddae3f6db79f2e9c46f8dfc83444b5e Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 22 Apr 2019 17:26:11 -0700
Subject: [PATCH] Improve UBSan discussion in etc/DEBUG

* etc/DEBUG: Improve -gdwarf-N documentation.
Go into more detail about UndefinedBehaviorSanitizer.
---
 etc/DEBUG | 40 +++++++++++++++++++++++++++-------------
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/etc/DEBUG b/etc/DEBUG
index 717553871a..836e820e4a 100644
--- a/etc/DEBUG
+++ b/etc/DEBUG
@@ -181,10 +181,10 @@ Good luck!
 
 ** When you are trying to analyze failed assertions or backtraces, it
 is essential to compile Emacs with flags suitable for debugging.
-With GCC 4.8 or later, you can invoke 'make' with CFLAGS="-O0 -g3".
-With older GCC, you can use CFLAGS="-O0 -g3 -gdwarf-4", replacing "4"
-by the highest version of DWARF that your compiler supports;
-with non-GCC compilers, "-O0 -g3" may be the best you can do.
+Although CFLAGS="-O0 -g3" often suffices with modern compilers,
+you may benefit further by using CFLAGS="-O0 -g3 -gdwarf-4", replacing
+"4" by the highest version of DWARF that your compiler supports;
+this is especially important for GCC versions older than 4.8.
 With GCC and higher optimization levels such as -O2, the
 -fno-omit-frame-pointer and -fno-crossjumping options are often
 essential.  The latter prevents GCC from using the same abort call for
@@ -917,13 +917,26 @@ setting the new-console option before running Emacs under GDB:
 
 ** Running Emacs with undefined-behavior sanitization
 
-Building Emacs with undefined-behavior sanitization can help debug
-integer overflow and other undefined behavior in C code.  To use
-UndefinedBehaviorSanitizer with GCC and similar compilers, append
-'-fsanitize=undefined' to CFLAGS, either when running 'configure' or
-running 'make'.  For example:
+Building Emacs with undefined-behavior sanitization can help find
+several kinds of low-level problems in C code, including:
 
-  ./configure CFLAGS='-O0 -g3 -fsanitize=undefined'
+  * Out-of-bounds access of many (but not all) arrays.
+  * Signed integer overflow, e.g., (INT_MAX + 1).
+  * Integer shifts by a negative or wider-than-word value.
+  * Misaligned pointers and pointer overflow.
+  * Loading a bool or enum value that is out of range for its type.
+  * Passing NULL to or returning NULL from a function requiring nonnull.
+  * Passing a size larger than the corresponding array to memcmp etc.
+  * Passing invalid values to some builtin functions, e.g., __builtin_clz (0).
+  * Reaching __builtin_unreachable calls (in Emacs, 'eassume' failure).
+
+To use UndefinedBehaviorSanitizer with GCC and similar compilers,
+append '-fsanitize=undefined' to CFLAGS, either when running
+'configure' or running 'make'.  When supported, you can also specify
+'bound-strict' and 'float-cast-overflow'.  For example:
+
+  ./configure \
+    CFLAGS='-O0 -g3 -fsanitize=undefined,bounds-strict,float-cast-overflow'
 
 You may need to append '-static-libubsan' to CFLAGS if your version of
 GCC is installed in an unusual location.
@@ -940,9 +953,10 @@ program.
 ** Running Emacs with address sanitization
 
 Building Emacs with address sanitization can help debug memory-use
-problems.  To use AddressSanitizer with GCC and similar compilers,
-append '-fsanitize=address' to CFLAGS, either when running 'configure'
-or running 'make'.  Configure, build and run Emacs with
+problems, such as freeing the same object twice.  To use
+AddressSanitizer with GCC and similar compilers, append
+'-fsanitize=address' to CFLAGS, either when running 'configure' or
+running 'make'.  Configure, build and run Emacs with
 ASAN_OPTIONS='detect_leaks=0' in the environment to suppress
 diagnostics of minor memory leaks in Emacs.  For example:
 
-- 
2.20.1


  reply	other threads:[~2019-04-23  0:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18 19:21 Errors building from master with a clean repository Alex Gramiak
2019-04-20  1:05 ` Paul Eggert
2019-04-20  6:48   ` Eli Zaretskii
2019-04-22  6:22     ` Paul Eggert
2019-04-22  7:45       ` Eli Zaretskii
2019-04-23  0:31         ` Paul Eggert [this message]
2019-04-23  6:05           ` Eli Zaretskii
2019-04-20 16:10   ` Alex Gramiak

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=84279731-9572-de3c-4806-a7c52fb79fee@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=agrambot@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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).