From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Contributing LLVM.org patches to gud.el Date: Wed, 11 Feb 2015 22:22:24 +0900 Message-ID: <87h9usoa5r.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87mw4rxkzv.fsf@fencepost.gnu.org> <87y4oavxcy.fsf@fencepost.gnu.org> <87d25juy8m.fsf@fencepost.gnu.org> <83iofa8lu2.fsf@gnu.org> <87wq3qrvjz.fsf@fencepost.gnu.org> <83386d92ox.fsf@gnu.org> <874mqtsoqy.fsf@fencepost.gnu.org> <83y4o57lfj.fsf@gnu.org> <87oap1nmef.fsf@uwakimon.sk.tsukuba.ac.jp> <54DAD0C3.9040103@dancol.org> <8761b8raxh.fsf@fencepost.gnu.org> <54DB343D.5070008@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1423660976 14049 80.91.229.3 (11 Feb 2015 13:22:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Feb 2015 13:22:56 +0000 (UTC) Cc: Eli Zaretskii , David Kastrup , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 11 14:22:46 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YLXFe-0004FM-8j for ged-emacs-devel@m.gmane.org; Wed, 11 Feb 2015 14:22:46 +0100 Original-Received: from localhost ([::1]:45023 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLXFd-0005UZ-K0 for ged-emacs-devel@m.gmane.org; Wed, 11 Feb 2015 08:22:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLXFW-0005Tz-8G for emacs-devel@gnu.org; Wed, 11 Feb 2015 08:22:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLXFV-0005fL-94 for emacs-devel@gnu.org; Wed, 11 Feb 2015 08:22:38 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:51902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLXFL-0005cl-IV; Wed, 11 Feb 2015 08:22:27 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E81FD1C38C2; Wed, 11 Feb 2015 22:22:24 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CFF6C1A26E3; Wed, 11 Feb 2015 22:22:24 +0900 (JST) In-Reply-To: <54DB343D.5070008@dancol.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182878 Archived-At: > On 02/11/2015 02:37 AM, David Kastrup wrote: > > The issue mostly are values which are not present explicitly > > anywhere. If the compiler can deduce the value/effect of a > > variable, it does not need to store it anywhere. I regularly see this with function arguments, IIRC including across linkage boundaries. I don't see how the compiler could deduce such values or their effects, except for cases like "(char) x < 1000". Daniel Colascione writes: > DWARF's virtual machine contains instructions for regenerating > these values from extant values and for building them out of thin > air. See section 2.5 of the DWARF 4 specification. GCC could emit > enough information to rebuild lost values, but does not. Eli mentioned DWARF 2. The manual for GCC 4.8.4 says: -g Produce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF 2). GDB can work with this debugging information. Later there is an option for specifying the version of DWARF, which cautions that use of DWARF 4 "may require gdb 7 and -fvar-tracking-assignments". I'll have to try that. For those of us who aren't gdb developers, it would be nice if gdb mentioned that use of DWARF 4 and special gcc options helps in debugging.