From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#13775: 24.3.50; Omissions in documentation for crash reporting Date: Sat, 23 Feb 2013 01:53:43 +0400 Message-ID: <5127E8E7.6090904@yandex.ru> References: <87bobei0tx.fsf@yandex.ru> <837gm1oa18.fsf@gnu.org> <5126CA8B.6040705@yandex.ru> <83k3q0n1l7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1361570099 12775 80.91.229.3 (22 Feb 2013 21:54:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Feb 2013 21:54:59 +0000 (UTC) Cc: 13775-done@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 22 22:55:22 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1U90aP-0003sm-8J for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Feb 2013 22:55:21 +0100 Original-Received: from localhost ([::1]:36975 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U90a4-0001JA-Sa for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Feb 2013 16:55:00 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:48408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U90Zy-0001IL-CE for bug-gnu-emacs@gnu.org; Fri, 22 Feb 2013 16:54:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U90Zi-0007Vy-SL for bug-gnu-emacs@gnu.org; Fri, 22 Feb 2013 16:54:54 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U90Zi-0007Vh-OT for bug-gnu-emacs@gnu.org; Fri, 22 Feb 2013 16:54:38 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U90b4-0001qn-6q for bug-gnu-emacs@gnu.org; Fri, 22 Feb 2013 16:56:02 -0500 Resent-From: Dmitry Gutov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Feb 2013 21:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 13775 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Mail-Followup-To: 13775@debbugs.gnu.org, dgutov@yandex.ru, dgutov@yandex.ru Original-Received: via spool by 13775-done@debbugs.gnu.org id=D13775.13615701126987 (code D ref 13775); Fri, 22 Feb 2013 21:56:01 +0000 Original-Received: (at 13775-done) by debbugs.gnu.org; 22 Feb 2013 21:55:12 +0000 Original-Received: from localhost ([127.0.0.1]:44751 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U90aF-0001oc-Ts for submit@debbugs.gnu.org; Fri, 22 Feb 2013 16:55:12 -0500 Original-Received: from mail-lb0-f180.google.com ([209.85.217.180]:47032) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U90aC-0001oT-2M for 13775-done@debbugs.gnu.org; Fri, 22 Feb 2013 16:55:09 -0500 Original-Received: by mail-lb0-f180.google.com with SMTP id q12so887054lbc.25 for <13775-done@debbugs.gnu.org>; Fri, 22 Feb 2013 13:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6oYm6P/JavpbJ7jayDejWNHHPACvpTPEKQ4vAKDi68s=; b=O209Z9qes2WMHJjHKlwFeI1D4TNUTcbHQiYdycEc9Gmp3ixAG/j5LH4rlGN5n24XLI 6xPtbRW7K0FzBcBKQk9MqARbI8HL2BsYioIx4FqHr4LD70yEwThar+/3XCi/Isalc/3g theg37tDovQQQMyKKSB+NKu88sK+zYESmwEfnfMioRclX0dXhhNmoHJxCQj03D8tX1v6 OVZIvyQIeK7Xlc/VMbIABLZ6M1SS7ymRzDa+IJIkxbPId8HVgfVgrVrEWQsQP+QaX537 5R4UVessr0SPXxbfgLQqM6DgbzRbuS8HcuBk76nP1y99DpXis2VcQkzkwguulhWR+5W/ fC9w== X-Received: by 10.112.42.134 with SMTP id o6mr1510941lbl.77.1361570022655; Fri, 22 Feb 2013 13:53:42 -0800 (PST) Original-Received: from [127.0.0.1] ([178.252.98.87]) by mx.google.com with ESMTPS id gm20sm2001274lab.7.2013.02.22.13.53.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 13:53:41 -0800 (PST) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 In-Reply-To: <83k3q0n1l7.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:71674 Archived-At: On 22.02.2013 13:24, Eli Zaretskii wrote: > I meant both the switches of configure and the compiler/linker > switches and options. > >> The ./configure --help output tells how to override switches in general, >> my complaint is about insufficient detail. Is the "Some influential >> environment variables" part provided by autoconf or somesuch? > > I don't understand the question. The relevant part of the help text You answered it below, "this is a standard text shown by ...". > is this: > > Some influential environment variables: > CC C compiler command > CFLAGS C compiler flags > LDFLAGS linker flags, e.g. -L if you have libraries in a > nonstandard directory > LIBS libraries to pass to the linker, e.g. -l > CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I if > you have headers in a nonstandard directory > CPP C preprocessor > XMKMF Path to xmkmf, Makefile generator for X Window System > > Use these variables to override the choices made by `configure' or to help > it to find libraries and programs with nonstandard names/locations. > > Which part(s) of this are unclear? > > In any case, this is a standard text shown by every configure script > out there, so if you think it should be clarified, please complain to > the Autoconf developers. Thanks, maybe I'll do that, sometime. >>>> 1. Calling `xbacktrace' requires src/.gdbinit to be loaded. It >>>> a) requires the user to run gdb exactly from src/ (not `gdb src/emacs'), >>> >>> The file etc/DEBUG tells you that at the beginning: >>> >>> ** When you debug Emacs with GDB, you should start it in the directory >>> where the executable was made. That directory has a .gdbinit file >>> that defines various "user-defined" commands for debugging Emacs. >>> (These commands are described below under "Examining Lisp object >>> values" and "Debugging Emacs Redisplay problems".) >> >> Um, yes, I read that. Maybe I should've skipped this part of the >> complaint. But is this exact wording ("the directory where the >> executable was made") important? If it just said "./src", that would be >> more obvious. > > I added that (revision 111290 on the emacs-24 branch). > >>>> b) requires them to modify the `auto-load safe-path', or that .gdbinit >>>> is ignored. >>> >>> This "feature" entered GDB only recently. Versions of GDB before 7.5 >>> don't need that, and will barf if you use this command. I don't see >>> any reasonable way of dealing with this without confusing newbies even >>> more (while veteran GDB users already know how to negotiate this >>> obstacle). >> >> If the feature isn't considered for removal, this argument will become >> less and less important over time. And the odds of a newbie being >> confused by safe-path will approach 100%. > > But GDB already tells you how to allow .gdbinit to be auto-loaded, and > also points to the GDB manual. If the text displayed by GDB is not > clear or confusing, I suggest to report that to GDB maintainers. > >> I'm not specifically asking to list the exact commands or ~/.gdbinit >> contents to work around safe-path. Maybe just mention the feature and, >> optionally, suggest consulting GDB manual, if that isn't obvious >> already? > > I added that to etc/DEBUG. > >> But specifying exactly what to do if GDB version is >= 7.5 >> would also work. > > That's hard to do, because the solution depends on the end-user's > preferences regarding security and on the degree of their machine's > exposure to other users and to the outside world. The GDB manual > discusses the possible solutions, so a pointer to it will allow the > user to make up her mind. > >>>> a) Do I set the variable when calling `make', or do I have to re-run >>>> ./configure? Not obvious, the answer is "the latter". >>> >>> Actually, both will work. >> >> Not exactly. >> >> 'CFLAGS="-g3" ./configure' works. >> 'CFLAGS="-g3" make' doesn't. >> >> 'make CFLAGS="-g3"' does work, but AFAIK that's not the usual way of >> binding an environment variable value. > > CFLAGS is a Make variable. Make normally initializes all its > variables by looking at the environment. But 'CFLAGS="-g3" make' > doesn't export the value of CFLAGS for Make to see it, it only inserts > CFLAGS into the shell's own environment. That is why the command > 'CFLAGS="-g3" make' doesn't work, while 'make CFLAGS="-g3"' does. I see, I think. > This is all standard shell and Make stuff, I don't think it's > reasonable to expect Emacs documentation to teach all that. > >> I think "compile without optimizations" or "compile for debugging" is a >> sufficiently common special case to warrant listing the recommended >> command somewhere in etc/DEBUG. That will take a few lines at the most. > > It's already there, it just didn't mention the -O0 option explicitly; > I added that. (Again, this is a basic compiler option, not something > specific to Emacs.) Like I described, my difficulty here was that using "-O0" by itself is not enough, without "-g3" the resulting build is even less debuggable. Omitting "-O0", leaving just "-g3", works, on the other hand, because the optimization is enabled by default due to the default CFLAGS value (AFAICT). Anyway, you've addressed that in 111290, as well as two other items. Thank you, I'm considering this issue fixed.