This is the mail archive of the gcc@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]

[wwwdocs] segfault.html (was Synthetic register related: Seg fault) - segfault.html [1/1]

[This followup was posted to gmane.comp.gcc.devel and a copy 
was sent to the cited author.]

In article <20030115194943.A16830@hg.cs.mu.OZ.AU>, 
fjh@cs.mu.OZ.AU says...
> On 15-Jan-2003, Andy Walker <ja_walker@earthlink.net> wrote:
> > What would be the best approach to hunting down flaws that cause things like 
> > this Segmentation fault?

I'm pretty sure this would make a good web page addition.  
Likely should be linked onto the bugs.html page.

So here it is.

Passed validator.w3.org as XHTML 1.0 transitional.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
<html xmlns="http://www.w3.org/1999/xhtml";>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
    <title>
      An approach to hunting down compiler flaws that cause things like
      Segmentation faults
    </title>
    <style type="text/css">
      code {color: red}
    </style>
  </head>
  <body>
    <h1>
      An approach to hunting down compiler flaws that cause things like
      Segmentation faults
    </h1>
    <address>
      By: Fergus Henderson &lt;fjh@cs.mu.OZ.AU&gt;
    </address>
    <hr />
    <p>
      Configure GCC with <code>--enable-checking</code>.&nbsp; Compile it with
      <code>-g</code> so that you can use gdb.
    </p>
    <p>
      Compile your test case with <code>-v -da -Q</code>.
    </p>
    <ul>
      <li>
        <code>-Q</code> will show which function in the test case is causing
        it to crash.
      </li>
      <li>
        <code>-v</code> shows how `cc1' was invoked (useful for invoking cc1
        manually in gdb).
      </li>
      <li>
        <code>-da</code> dumps the RTL to a file after each stage.
      </li>
    </ul>
    <p>
      Next, use gdb to get a stack trace.&nbsp; Compile the compiler with
      debugging enabled (<code>-g</code>), use the <code>-v</code> option to see how cc1 is getting
      invoked, and then do
    </p>
     
    <div style="margin-left: 40px;">
      bash$ <code>gdb cc1</code><br />
       gdb&gt; <code>run &lt;arguments&gt;</code><br />
       &hellip; (it will stop at the Seg fault)<br />
       gdb&gt; <code>where</code><br />
       &hellip;<br />
       gdb&gt; <code>list</code>
    </div>
     
    <p>
      Print out the values of interesting variables (e.g. the ones in the
      statement which got a segmentation fault).
    </p>
    <p>
      You can use the <code>pt</code> and <code>pr</code> macros from the
      gdbinit.in file to display them.&nbsp; For example, if there is a value
      of type <code>tree</code> named <code>t</code>, and a value of type
      <code>rtx</code> named <code>r</code>, you can use these commands:
    </p>
     
    <div style="margin-left: 40px;">
      gdb&gt; <code>source .gdbinit</code><br />
       gdb&gt; <code>print t</code><br />
       gdb&gt; <code>pt</code><br />
       gdb&gt; <code>print r</code><br />
       gdb&gt; <code>pr</code><br />
       gdb&gt; <code>pt</code><br />
    </div>
  </body>
</html>
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]