This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Remove gccbug from bugreport.texi, take 3


On Tue, 13 May 2003, Wolfgang Bangerth wrote:
>> let Gerald look at it as well

I had a close look, and the patch looks fine with a single change:

> ! A copy of this file should also be part of the
> ! documentation that comes with GCC releases.

Please provide the actual filesnames (bugs.html and BUGS, IIRC).

Go ahead and apply the patch to mainline and the 3.3 (immediately after
it's open again) with this change, but please consider updating bugs.html
taking the notes below into account, especially the first two.

Thanks,
Gerald

> Index: doc/bugreport.texi
> ===================================================================
> ! Keep in mind that the purpose of a bug report is to enable someone to
> ! fix the bug if it is not known.
> [...]
> ! Try to make your bug report self-contained.

I suggest to mention these two overall goals prominently at the beginning
of bugs.html.

> ! @item
> ! If you send examples of assembler code output from GCC,
> ! please use @option{-g} when you make them.  The debugging information
> ! includes source line numbers which are essential for correlating the
> ! output with the input.

bugs.html currently lacks this piece of information.

> ! @item
> ! Additional information from a debugger might enable someone to find a
> ! problem on a machine which he does not have available.  However, you
> ! need to think when you collect this information if you want it to have
> ! any chance of being useful.
> !
> ! @cindex backtrace for bug reports
> ! For example, many people send just a backtrace, but that is never
> ! useful by itself.  A simple backtrace with arguments conveys little
> ! about GCC because the compiler is largely data-driven; the same
> ! functions are called over and over for different RTL insns, doing
> ! different things depending on the details of the insn.
> !
> ! Most of the arguments listed in the backtrace are useless because they
> ! are pointers to RTL list structure.  The numeric values of the
> ! pointers, which the debugger prints in the backtrace, have no
> ! significance whatever; all that matters is the contents of the objects
> ! they point to (and most of the contents are other such pointers).
> !
> ! In addition, most compiler passes consist of one or more loops that
> ! scan the RTL insn sequence.  The most vital piece of information about
> ! such a loop---which insn it has reached---is usually in a local variable,
> ! not in an argument.
> !
> ! @findex debug_rtx
> ! What you need to provide in addition to a backtrace are the values of
> ! the local variables for several stack frames up.  When a local
> ! variable or an argument is an RTX, first print its value and then use
> ! the GDB command @code{pr} to print the RTL expression that it points
> ! to.  (If GDB doesn't run on your machine, use your debugger to call
> ! the function @code{debug_rtx} with the RTX as an argument.)  In
> ! general, whenever a variable is a pointer, its value is no use
> ! without the data it points to.
> ! @end itemize

bugs.html doesn't have anything in this, but I'm not sure whether it's
really (1) up-to-date, (2) appropriate to have there.

Gerald


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]