--- Begin Message ---
Subject: |
24.3.50; Omissions in documentation for crash reporting |
Date: |
Thu, 21 Feb 2013 11:27:06 +0400 |
As a non-GDB-wielding user with not much C experience, I had a hard time
following the instructions in `report-emacs-bug' and the ones that
followed.
1. Calling `xbacktrace' requires src/.gdbinit to be loaded. It
a) requires the user to run gdb exactly from src/ (not `gdb src/emacs'),
b) requires them to modify the `auto-load safe-path', or that .gdbinit
is ignored.
2. "Compile without optimizations" - how do I do that? `configure
--help' doesn't seem to show any pertinent options. ...but wait, it says
I can override the choices made by the script.
a) Do I set the variable when calling `make', or do I have to re-run
./configure? Not obvious, the answer is "the latter".
b) I don't know the choice the script made, how do I not break
anything by overriding it? My first choice was "-O0", and that resulted
in an unoptimized build with no debugging symbols (I think).
3. In #13749 (which caused me to write this), Paul also suggests using
-DENABLE_CHECKING. If I'm not mistaken, this variable isn't documented
anywhere.
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#13775: 24.3.50; Omissions in documentation for crash reporting |
Date: |
Sat, 23 Feb 2013 01:53:43 +0400 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 |
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<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
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.
--- End Message ---