Sender: root AT delorie DOT com
Message-ID: <38BBC78A.B416715E@inti.gov.ar>
Date: Tue, 29 Feb 2000 10:20:10 -0300
From: salvador <salvador AT inti DOT gov DOT ar>
Organization: INTI
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.38 i686)
X-Accept-Language: es-AR, en, es
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Debugging difficulties with GCC 2.95.2
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000227093924 DOT 14604A-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:

> > I had noticed that there was
> > a discrepency in the way line-number based debug information was handled
> > by the BFD library, between COFF and .stabs symbols.
>
> This doesn't seem to be related to COFF vs stabs, since compiling with
> -gstabsN has the same problem for all levels of N up to 3; only -gstabs+
> somehow manages to convince the debugger that there are some source
> lines in dfunc.  I don't know enough about stabs to see something
> interesting in comparison of the output of -gstabs3 and -gstabs+.

BTW, I see a lot of crazy things using gdb 4.18 (from RHIDE) and gcc 2.95.1,
like functions where the first steped line is at the end (small ones) so after
steping a little more you go back! and then revisit the line! and was using
-gstabs+3, so something is really broken.

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
                    set AT ieee DOT org set-soft AT bigfoot DOT com
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013