Synthetic register related: Seg fault

Synthetic register related: Seg fault

[Andy Walker]

I have managed to beat the code into shape.  I am minimally satisfied that 
the overal design changes implement the functionality I am trying to create. 

Now I have to excise the dumb stunts.

I have modified five to seven hundred lines of code, spread out over i368.c, 
i386.h, i386.md, and i386-protos.(h?), not counting necessary global 
replacements.  This isn't much code, nothing is terribly creative, and all of 
the new code is merely duplication with a slight twist.  

For the most part, this is just straightforward bashing on the places where 
it looked like it needed to be changed.

The whole thing (amazingly) compiles, and I believe it gets past the first 
MAKE step for make bootstrap.

What would be the best approach to hunting down flaws that cause things like 
this Segmentation fault?

Andy

Re: Synthetic register related: Seg fault

[Fergus Henderson]

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?

Configure GCC with --enable-checking.
Compile it with `-g' so that you can use gdb.

Compile your test case with `-v -da -Q'.
`-Q' will show which function in the test case is causing it to crash.
`-v' shows how `cc1' was invoked (useful for invoking cc1 manually in
gdb).  `-da' dumps the RTL to a file after each stage.

Use gdb to get a stack trace.
Compile the compiler with debugging enabled (-g),
use the `-v' option to see how cc1 is getting invoked,
and then do

	bash$ gdb cc1
	gdb> run <arguments>
	... (it will stop at the Seg fault)
	gdb> where
	...
	gdb> list

Print out the values of interesting variables (e.g. the ones
in the statement which got a segmentation fault).
You can use the `pt' and `pr' macros from the gdbinit.in file to
display them.  For example, if there is a value of type `tree' named
`t', and a value of type `rtx' named `r', you can use these commands:

	gdb> source .gdbinit
	gdb> print t
	gdb> pt
	gdb> print r
	gdb> pr
	gdb> pt

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: Synthetic register related: Seg fault

[Lars Segerlund]

Thanks, this is tremendously good info, it will make some things much 
more easy for me :-) ... I have been needing something like this for a time.

  / regards, Lars Segerlund.

Fergus Henderson wrote:
> 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?
> 
> 
> Configure GCC with --enable-checking.
> Compile it with `-g' so that you can use gdb.
> 
> Compile your test case with `-v -da -Q'.
> `-Q' will show which function in the test case is causing it to crash.
> `-v' shows how `cc1' was invoked (useful for invoking cc1 manually in
> gdb).  `-da' dumps the RTL to a file after each stage.
> 
> Use gdb to get a stack trace.
> Compile the compiler with debugging enabled (-g),
> use the `-v' option to see how cc1 is getting invoked,
> and then do
> 
> 	bash$ gdb cc1
> 	gdb> run <arguments>
> 	... (it will stop at the Seg fault)
> 	gdb> where
> 	...
> 	gdb> list
> 
> Print out the values of interesting variables (e.g. the ones
> in the statement which got a segmentation fault).
> You can use the `pt' and `pr' macros from the gdbinit.in file to
> display them.  For example, if there is a value of type `tree' named
> `t', and a value of type `rtx' named `r', you can use these commands:
> 
> 	gdb> source .gdbinit
> 	gdb> print t
> 	gdb> pt
> 	gdb> print r
> 	gdb> pr
> 	gdb> pt
> 

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

[Kelley Cook]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

[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.


[-- Attachment #2: HTMLized version of segfault instructions --]
[-- Type: Text/Plain, Size: 2619 bytes --]

<!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>

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

[Janis Johnson]

On Thu, Jan 16, 2003 at 11:46:30AM -0500, Kelley Cook wrote:
> [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.

Cool!  I was thinking of turning that into a web page but you beat me
to it.

Lots of suggestions:

 o  The DOCTYPE stuff isn't included in the files that are in
    wwwdocs/htdocs, but is added by a tool before they are copied to
    the web pages.

 o  The web pages themselves don't specify styles; Gerald can provide
    more information about that.

 o  Web pages don't generally say who wrote them, although that info
    can be in the CVS log.

 o  The title is rather long; how about "How to Debug a GCC Seg Fault."

 o  Our other howto documents are called *-howto.html.

Gerald suggested that I create a new directory called bugs and move the
current bugs.html to bugs/index.html, updating all of the places that
reference the current file.  Then reghunt-howto can be moved there, plus
the document Wolfgang is writing about minimizing test cases, and now
this new one.  Another thing I'd like to see there is how to identify
code (from a large app) that fails for particular optimizations.

Janis

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

[Joseph S. Myers]

On Thu, 16 Jan 2003, Janis Johnson wrote:

> Gerald suggested that I create a new directory called bugs and move the
> current bugs.html to bugs/index.html, updating all of the places that
> reference the current file.  Then reghunt-howto can be moved there, plus

Moving bugs.html is problematic - you can't just redirect with .htaccess
as is normal when moving files [1], because the URL given by installed
compilers is that on www.gnu.org and .htaccess doesn't get rewritten to
handle the different paths on www.gnu.org.  Thus a bugs.html file needs to
stay around forever with a redirecting link (and maybe meta
http-equiv=refresh) for users accessing the www.gnu.org file.

[1] Apparently not documented in the GCC Coding Conventions, but we try to
avoid breaking people's links and bookmarks.  For example, we use
.htaccess when renaming files (or merging one file into another), and all
the manuals for old releases in onlinedocs stay around forever even though
we only link to the manual for the most recent release in each release
series - someone might have the 2.95.2, 3.0.1, ... manual bookmarked or
linked to, and there are references to them in the list archives.

http://www.w3.org/Provider/Style/URI
http://www.useit.com/alertbox/981129.html

-- 
Joseph S. Myers
jsm28@cam.ac.uk

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

[Janis Johnson]

On Thu, Jan 16, 2003 at 07:28:03PM +0000, Joseph S. Myers wrote:
> On Thu, 16 Jan 2003, Janis Johnson wrote:
> 
> > Gerald suggested that I create a new directory called bugs and move the
> > current bugs.html to bugs/index.html, updating all of the places that
> > reference the current file.  Then reghunt-howto can be moved there, plus
> 
> Moving bugs.html is problematic - you can't just redirect with .htaccess
> as is normal when moving files [1], because the URL given by installed
> compilers is that on www.gnu.org and .htaccess doesn't get rewritten to
> handle the different paths on www.gnu.org.  Thus a bugs.html file needs to
> stay around forever with a redirecting link (and maybe meta
> http-equiv=refresh) for users accessing the www.gnu.org file.

Yes, Gerald said it would be more complicated than usual for this
particular file, and I haven't looked into it yet.  If you've got
specific recommendations, including the option of leaving that file
alone, you can send them to me privately.

Janis