Re: Errors building from master with a clean repository

[Eli Zaretskii <eliz@gnu.org>]

> Cc: agrambot@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 21 Apr 2019 23:22:19 -0700
> 
> > Can we please at least mention
> > specific compiler options and any other tools that could be used
> > instead of the built-in facilities we are removing?  Bonus points for
> > adding to etc/DEBUG a section with more details about the compiler
> > options, tools, and techniques of using them for debugging specific
> > Emacs problems for which these configure options were introduced.
> 
> OK, I tried to earn bonus points by installing the attached patch into master, 
> on top of the two other patches I mentioned earlier.

Thanks, I have a few comments:

> -Modern versions of GCC support more elaborate debug info that is
> -available by just using the -g3 compiler switch.  Try using -gdwarf-4
> -in addition to -g3, and if that fails, try -gdwarf-3.  This is
> -especially important if you have to debug optimized code.  More info
> -about this is available below; search for "analyze failed assertions".
> +Older versions of GCC may need more than just the -g3 flag.  For more,
> +search for "analyze failed assertions" below.

You have consistently removed the references to -gdwarf-N compiler
option, presumably on the assumption that GCC nowadays automatically
uses the highest supported version?  But that doesn't seem to be the
case here, at least with GCC 7.3.0 on MS-Windows: using -g3 produces
DWARF2 info Version 4, but I can use -gdwarf-5 to produce Version 5.
So I wonder whether the assumption about -g3 is valid.

> -** Running Emacs built with malloc debugging packages
> +** Running Emacs with undefined-behavior sanitization
>  
> -If Emacs exhibits bugs that seem to be related to use of memory
> -allocated off the heap, it might be useful to link Emacs with a
> -special debugging library, such as Electric Fence (a.k.a. efence) or
> -GNU Checker, which helps find such problems.
> +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:

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