Re: Input stream crash with gcc 3.1/cygwin (stack trace incl.)

["Dylan Cuthbert" <dylan at q-games dot com>]

Hi again, I seem to remember chatting to you years ago regarding the TI 128
bit extensions.

I'm all too familiar with the debugging process, however gdb 5.0 and 5.1
crash with a segmentation fault when I try to read the executables generated
by gcc 3.1 (it works fine with output from 3.0.3), I presume something has
slightly changed with the elf format or maybe its even related to the same
problem?

What I'm more interested in is if anyone has had a similar problem to this
on another platform and knows of a particular direction to start looking at
the code.

Of course, it would *really* help if someone had an inkling on how to get
gdb to work :-(

Unfortunately I've already spent a week or 2 on this problem with almost nil
response from the gcc lists to help me track it down and I just can't spare
any more time.  I'll come back to the problem the next time my schedule
opens up in a month or 2, in the meantime I'm back on 3.0.3.

I presume everybody's busy fixing stuff for the proposed April release of
3.1.

Regards

---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com/personal/utils

----- Original Message -----
From: "mike stump" <mrs@windriver.com>
To: <dylan@q-games.com>
Sent: Tuesday, March 26, 2002 9:18 AM
Subject: Re: Input stream crash with gcc 3.1/cygwin (stack trace incl.)


> > From: "Dylan Cuthbert" <dylan@q-games.com>
> > To: <gcc@gcc.gnu.org>
> > Cc: <gcc@gcc.gnu.org>
> > Date: Mon, 25 Mar 2002 13:03:52 +0900
>
> > Does anybody have any ideas on how to track this problem down?
>
> Sure, there is a process called debugging that can be used to track
> this down.  No, I don't know of an easier or better or faster way.
>
> Roughly, you compile everything with -g, start up gdb, and then run
> your software.  You then have to figure out where it went wrong and
> why.
>
> You can issue a si command, and then ask yourself if that code is a
> correct translation of the source code, if it is, then you can do it
> again.  If not, then that is a compiler bug, and you can file a bug
> report for the .i or .ii file that contains that oject code.  If it
> is, and you get to the `failure', and you don't want it, then it is a
> bug in the program source software (or runtime library).
>
> There are additional techniques to make the process faster and
> easier...
>
> Additional details are well beyond the scope of any of these lists,
> except maybe gcc-help.