You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
241 lines
11 KiB
HTML
241 lines
11 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<!-- Copyright (C) 1988-2019 Free Software Foundation, Inc.
|
|
|
|
Permission is granted to copy, distribute and/or modify this document
|
|
under the terms of the GNU Free Documentation License, Version 1.3 or
|
|
any later version published by the Free Software Foundation; with the
|
|
Invariant Sections being "Free Software" and "Free Software Needs
|
|
Free Documentation", with the Front-Cover Texts being "A GNU Manual,"
|
|
and with the Back-Cover Texts as in (a) below.
|
|
|
|
(a) The FSF's Back-Cover Text is: "You are free to copy and modify
|
|
this GNU Manual. Buying copies from GNU Press supports the FSF in
|
|
developing GNU and promoting software freedom." -->
|
|
<!-- Created by GNU Texinfo 6.4, http://www.gnu.org/software/texinfo/ -->
|
|
<head>
|
|
<title>Bug Reporting (Debugging with GDB)</title>
|
|
|
|
<meta name="description" content="Bug Reporting (Debugging with GDB)">
|
|
<meta name="keywords" content="Bug Reporting (Debugging with GDB)">
|
|
<meta name="resource-type" content="document">
|
|
<meta name="distribution" content="global">
|
|
<meta name="Generator" content="makeinfo">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<link href="index.html#Top" rel="start" title="Top">
|
|
<link href="Concept-Index.html#Concept-Index" rel="index" title="Concept Index">
|
|
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
|
|
<link href="GDB-Bugs.html#GDB-Bugs" rel="up" title="GDB Bugs">
|
|
<link href="Command-Line-Editing.html#Command-Line-Editing" rel="next" title="Command Line Editing">
|
|
<link href="Bug-Criteria.html#Bug-Criteria" rel="prev" title="Bug Criteria">
|
|
<style type="text/css">
|
|
<!--
|
|
a.summary-letter {text-decoration: none}
|
|
blockquote.indentedblock {margin-right: 0em}
|
|
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
|
|
blockquote.smallquotation {font-size: smaller}
|
|
div.display {margin-left: 3.2em}
|
|
div.example {margin-left: 3.2em}
|
|
div.lisp {margin-left: 3.2em}
|
|
div.smalldisplay {margin-left: 3.2em}
|
|
div.smallexample {margin-left: 3.2em}
|
|
div.smalllisp {margin-left: 3.2em}
|
|
kbd {font-style: oblique}
|
|
pre.display {font-family: inherit}
|
|
pre.format {font-family: inherit}
|
|
pre.menu-comment {font-family: serif}
|
|
pre.menu-preformatted {font-family: serif}
|
|
pre.smalldisplay {font-family: inherit; font-size: smaller}
|
|
pre.smallexample {font-size: smaller}
|
|
pre.smallformat {font-family: inherit; font-size: smaller}
|
|
pre.smalllisp {font-size: smaller}
|
|
span.nolinebreak {white-space: nowrap}
|
|
span.roman {font-family: initial; font-weight: normal}
|
|
span.sansserif {font-family: sans-serif; font-weight: normal}
|
|
ul.no-bullet {list-style: none}
|
|
-->
|
|
</style>
|
|
|
|
|
|
</head>
|
|
|
|
<body lang="en">
|
|
<a name="Bug-Reporting"></a>
|
|
<div class="header">
|
|
<p>
|
|
Previous: <a href="Bug-Criteria.html#Bug-Criteria" accesskey="p" rel="prev">Bug Criteria</a>, Up: <a href="GDB-Bugs.html#GDB-Bugs" accesskey="u" rel="up">GDB Bugs</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html#Concept-Index" title="Index" rel="index">Index</a>]</p>
|
|
</div>
|
|
<hr>
|
|
<a name="How-to-Report-Bugs"></a>
|
|
<h3 class="section">31.2 How to Report Bugs</h3>
|
|
<a name="index-bug-reports"></a>
|
|
<a name="index-GDB-bugs_002c-reporting"></a>
|
|
|
|
<p>A number of companies and individuals offer support for <small>GNU</small> products.
|
|
If you obtained <small>GDB</small> from a support organization, we recommend you
|
|
contact that organization first.
|
|
</p>
|
|
<p>You can find contact information for many support companies and
|
|
individuals in the file <samp>etc/SERVICE</samp> in the <small>GNU</small> Emacs
|
|
distribution.
|
|
</p>
|
|
<p>In any event, we also recommend that you submit bug reports for
|
|
<small>GDB</small> to <a href="https://github.com/sifive/freedom-tools/issues">https://github.com/sifive/freedom-tools/issues</a>.
|
|
</p>
|
|
<p>The fundamental principle of reporting bugs usefully is this:
|
|
<strong>report all the facts</strong>. If you are not sure whether to state a
|
|
fact or leave it out, state it!
|
|
</p>
|
|
<p>Often people omit facts because they think they know what causes the
|
|
problem and assume that some details do not matter. Thus, you might
|
|
assume that the name of the variable you use in an example does not matter.
|
|
Well, probably it does not, but one cannot be sure. Perhaps the bug is a
|
|
stray memory reference which happens to fetch from the location where that
|
|
name is stored in memory; perhaps, if the name were different, the contents
|
|
of that location would fool the debugger into doing the right thing despite
|
|
the bug. Play it safe and give a specific, complete example. That is the
|
|
easiest thing for you to do, and the most helpful.
|
|
</p>
|
|
<p>Keep in mind that the purpose of a bug report is to enable us to fix the
|
|
bug. It may be that the bug has been reported previously, but neither
|
|
you nor we can know that unless your bug report is complete and
|
|
self-contained.
|
|
</p>
|
|
<p>Sometimes people give a few sketchy facts and ask, “Does this ring a
|
|
bell?” Those bug reports are useless, and we urge everyone to
|
|
<em>refuse to respond to them</em> except to chide the sender to report
|
|
bugs properly.
|
|
</p>
|
|
<p>To enable us to fix the bug, you should include all these things:
|
|
</p>
|
|
<ul>
|
|
<li> The version of <small>GDB</small>. <small>GDB</small> announces it if you start
|
|
with no arguments; you can also print it at any time using <code>show
|
|
version</code>.
|
|
|
|
<p>Without this, we will not know whether there is any point in looking for
|
|
the bug in the current version of <small>GDB</small>.
|
|
</p>
|
|
</li><li> The type of machine you are using, and the operating system name and
|
|
version number.
|
|
|
|
</li><li> The details of the <small>GDB</small> build-time configuration.
|
|
<small>GDB</small> shows these details if you invoke it with the
|
|
<samp>--configuration</samp> command-line option, or if you type
|
|
<code>show configuration</code> at <small>GDB</small>’s prompt.
|
|
|
|
</li><li> What compiler (and its version) was used to compile <small>GDB</small>—e.g.
|
|
“gcc–2.8.1”.
|
|
|
|
</li><li> What compiler (and its version) was used to compile the program you are
|
|
debugging—e.g. “gcc–2.8.1”, or “HP92453-01 A.10.32.03 HP
|
|
C Compiler”. For <small>GCC</small>, you can say <kbd>gcc --version</kbd>
|
|
to get this information; for other compilers, see the documentation for
|
|
those compilers.
|
|
|
|
</li><li> The command arguments you gave the compiler to compile your example and
|
|
observe the bug. For example, did you use ‘<samp>-O</samp>’? To guarantee
|
|
you will not omit something important, list them all. A copy of the
|
|
Makefile (or the output from make) is sufficient.
|
|
|
|
<p>If we were to try to guess the arguments, we would probably guess wrong
|
|
and then we might not encounter the bug.
|
|
</p>
|
|
</li><li> A complete input script, and all necessary source files, that will
|
|
reproduce the bug.
|
|
|
|
</li><li> A description of what behavior you observe that you believe is
|
|
incorrect. For example, “It gets a fatal signal.”
|
|
|
|
<p>Of course, if the bug is that <small>GDB</small> gets a fatal signal, then we
|
|
will certainly notice it. But if the bug is incorrect output, we might
|
|
not notice unless it is glaringly wrong. You might as well not give us
|
|
a chance to make a mistake.
|
|
</p>
|
|
<p>Even if the problem you experience is a fatal signal, you should still
|
|
say so explicitly. Suppose something strange is going on, such as, your
|
|
copy of <small>GDB</small> is out of synch, or you have encountered a bug in
|
|
the C library on your system. (This has happened!) Your copy might
|
|
crash and ours would not. If you told us to expect a crash, then when
|
|
ours fails to crash, we would know that the bug was not happening for
|
|
us. If you had not told us to expect a crash, then we would not be able
|
|
to draw any conclusion from our observations.
|
|
</p>
|
|
<a name="index-script"></a>
|
|
<a name="index-recording-a-session-script"></a>
|
|
<p>To collect all this information, you can use a session recording program
|
|
such as <code>script</code>, which is available on many Unix systems.
|
|
Just run your <small>GDB</small> session inside <code>script</code> and then
|
|
include the <samp>typescript</samp> file with your bug report.
|
|
</p>
|
|
<p>Another way to record a <small>GDB</small> session is to run <small>GDB</small>
|
|
inside Emacs and then save the entire buffer to a file.
|
|
</p>
|
|
</li><li> If you wish to suggest changes to the <small>GDB</small> source, send us context
|
|
diffs. If you even discuss something in the <small>GDB</small> source, refer to
|
|
it by context, not by line number.
|
|
|
|
<p>The line numbers in our development sources will not match those in your
|
|
sources. Your line numbers would convey no useful information to us.
|
|
</p>
|
|
</li></ul>
|
|
|
|
<p>Here are some things that are not necessary:
|
|
</p>
|
|
<ul>
|
|
<li> A description of the envelope of the bug.
|
|
|
|
<p>Often people who encounter a bug spend a lot of time investigating
|
|
which changes to the input file will make the bug go away and which
|
|
changes will not affect it.
|
|
</p>
|
|
<p>This is often time consuming and not very useful, because the way we
|
|
will find the bug is by running a single example under the debugger
|
|
with breakpoints, not by pure deduction from a series of examples.
|
|
We recommend that you save your time for something else.
|
|
</p>
|
|
<p>Of course, if you can find a simpler example to report <em>instead</em>
|
|
of the original one, that is a convenience for us. Errors in the
|
|
output will be easier to spot, running under the debugger will take
|
|
less time, and so on.
|
|
</p>
|
|
<p>However, simplification is not vital; if you do not want to do this,
|
|
report the bug anyway and send us the entire test case you used.
|
|
</p>
|
|
</li><li> A patch for the bug.
|
|
|
|
<p>A patch for the bug does help us if it is a good one. But do not omit
|
|
the necessary information, such as the test case, on the assumption that
|
|
a patch is all we need. We might see problems with your patch and decide
|
|
to fix the problem another way, or we might not understand it at all.
|
|
</p>
|
|
<p>Sometimes with a program as complicated as <small>GDB</small> it is very hard to
|
|
construct an example that will make the program follow a certain path
|
|
through the code. If you do not send us the example, we will not be able
|
|
to construct one, so we will not be able to verify that the bug is fixed.
|
|
</p>
|
|
<p>And if we cannot understand what bug you are trying to fix, or why your
|
|
patch should be an improvement, we will not install it. A test case will
|
|
help us to understand.
|
|
</p>
|
|
</li><li> A guess about what the bug is or what it depends on.
|
|
|
|
<p>Such guesses are usually wrong. Even we cannot guess right about such
|
|
things without first using the debugger to find the facts.
|
|
</p></li></ul>
|
|
|
|
|
|
|
|
|
|
|
|
<hr>
|
|
<div class="header">
|
|
<p>
|
|
Previous: <a href="Bug-Criteria.html#Bug-Criteria" accesskey="p" rel="prev">Bug Criteria</a>, Up: <a href="GDB-Bugs.html#GDB-Bugs" accesskey="u" rel="up">GDB Bugs</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html#Concept-Index" title="Index" rel="index">Index</a>]</p>
|
|
</div>
|
|
|
|
|
|
|
|
</body>
|
|
</html>
|