diff options
| author | alk3pInjection <webmaster@raspii.tech> | 2024-02-04 16:16:35 +0800 |
|---|---|---|
| committer | alk3pInjection <webmaster@raspii.tech> | 2024-02-04 16:16:35 +0800 |
| commit | abdaadbcae30fe0c9a66c7516798279fdfd97750 (patch) | |
| tree | 00a54a6e25601e43876d03c1a4a12a749d4a914c /share/doc/gdb/Bug-Reporting.html | |
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Change-Id: I7303388733328cd98ab9aa3c30236db67f2e9e9c
Diffstat (limited to 'share/doc/gdb/Bug-Reporting.html')
| -rw-r--r-- | share/doc/gdb/Bug-Reporting.html | 241 |
1 files changed, 241 insertions, 0 deletions
diff --git a/share/doc/gdb/Bug-Reporting.html b/share/doc/gdb/Bug-Reporting.html new file mode 100644 index 0000000..f7540de --- /dev/null +++ b/share/doc/gdb/Bug-Reporting.html @@ -0,0 +1,241 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html> +<!-- Copyright (C) 1988-2023 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 5.1, http://www.gnu.org/software/texinfo/ --> +<head> +<title>Debugging with GDB: Bug Reporting</title> + +<meta name="description" content="Debugging with GDB: Bug Reporting"> +<meta name="keywords" content="Debugging with GDB: Bug Reporting"> +<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="previous" title="Bug Criteria"> +<style type="text/css"> +<!-- +a.summary-letter {text-decoration: none} +blockquote.smallquotation {font-size: smaller} +div.display {margin-left: 3.2em} +div.example {margin-left: 3.2em} +div.indentedblock {margin-left: 3.2em} +div.lisp {margin-left: 3.2em} +div.smalldisplay {margin-left: 3.2em} +div.smallexample {margin-left: 3.2em} +div.smallindentedblock {margin-left: 3.2em; font-size: smaller} +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.nocodebreak {white-space:nowrap} +span.nolinebreak {white-space:nowrap} +span.roman {font-family:serif; font-weight:normal} +span.sansserif {font-family:sans-serif; font-weight:normal} +ul.no-bullet {list-style: none} +--> +</style> + + +</head> + +<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> +<a name="Bug-Reporting"></a> +<div class="header"> +<p> +Previous: <a href="Bug-Criteria.html#Bug-Criteria" accesskey="p" rel="previous">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://bugs.linaro.org/">https://bugs.linaro.org/</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="previous">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> |