Date: Thu, 16 Apr 1998 09:59:52 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Thomas Demmer <demmer AT LSTM DOT Ruhr-UNI-Bochum DOT De>
cc: djgpp AT delorie DOT com
Subject: Re: strip.exe and -gstabs broken
In-Reply-To: <3534ED10.4AD5DF9B@LSTM.Ruhr-UNI-Bochum.De>
Message-ID: <Pine.SUN.3.91.980416095934.12532C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 15 Apr 1998, Thomas Demmer wrote:

> SET has a patched version of gcc 2.7.2.1 on his homepage that 
> supports the stabs debugging info format. Compiling
> C++ code with -gstabs allows some nice debugging possibilities
> that the usual -g does not. However, running strip.exe on the
> executable seems to ruin the image, I guess already the startup
> code. The only thing you get is a "General Protection Fault",
> nothing else. 

Isn't this problem due to the fact that Binutils 2.7 were not
configured to support stabs?  Which strip did you use?  Was it from
Binutils 2.8.1 or 2.7?

> Eli proposed to use -gxcoff instead, but that only gets you a warning
> "debugging format not supported by this version of gcc".

I think I said -gcoff, not -gxcoff.  (At least, that's what I *meant*
to say.)  -gcoff should work.

> I am not sure if 2.8 supports stabs, but I guess that if so, strip.exe
> will ruin those images, too. The only way around this, so far, is
> to rebuild all without debugging info...

Did you try stripping the raw COFF image?  For example:

    exe2coff foo.exe
    strip foo
    stubify foo
    del foo

Does this work with stabs debugging?  If the problem is with the stub,
then the above should provide a work-around.