From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Errors building from master with a clean repository Date: Mon, 22 Apr 2019 10:45:23 +0300 Message-ID: <83a7gi8ovg.fsf@gnu.org> References: <87ef5z9l23.fsf@gmail.com> <7db3cae7-794c-83d6-b8f4-f0ec000d1674@cs.ucla.edu> <83o951b29x.fsf@gnu.org> <58b59f1d-94ee-cffc-f711-b4fdcdb0b471@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="166672"; mail-complaints-to="usenet@blaine.gmane.org" Cc: agrambot@gmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 22 09:46:17 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hITea-000hEY-P3 for ged-emacs-devel@m.gmane.org; Mon, 22 Apr 2019 09:46:16 +0200 Original-Received: from localhost ([127.0.0.1]:33812 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hITeZ-0001JM-Nb for ged-emacs-devel@m.gmane.org; Mon, 22 Apr 2019 03:46:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hITdv-0001IH-Ae for emacs-devel@gnu.org; Mon, 22 Apr 2019 03:45:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36680) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hITdu-0004eM-Jv; Mon, 22 Apr 2019 03:45:35 -0400 Original-Received: from [176.228.60.248] (port=2217 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hITds-0002Ts-M1; Mon, 22 Apr 2019 03:45:34 -0400 In-reply-to: <58b59f1d-94ee-cffc-f711-b4fdcdb0b471@cs.ucla.edu> (message from Paul Eggert on Sun, 21 Apr 2019 23:22:19 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235756 Archived-At: > Cc: agrambot@gmail.com, emacs-devel@gnu.org > From: Paul Eggert > 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.