X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Thu, 2 Mar 2000 14:47:18 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp-workers AT delorie DOT com
Subject:	Re: Debugging difficulties with GCC 2.95.2
In-Reply-To:	<Pine.SUN.3.91.1000227093924.14604A-100000@is>
Message-ID:	<Pine.LNX.4.10.10003021405310.11752-100000@acp3bf>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sun, 27 Feb 2000, Eli Zaretskii wrote:
> On Thu, 24 Feb 2000, Hans-Bernhard Broeker wrote:
[...]

> > Have you had a look at the assembly source the example compiles to?
> 
> I have now.  Here's a side-by-side comparison of the code produced by
> GCC 2.95.2, with and without optimizations, for the following function 
> dfunc

[...]

> Note that in the optimized version, the ".ln 3" directive is *after*
> the RET instruction, and ".ln 2" is *before* the function's usual
> "push %ebp", "mov %esp,%ebp" prologue.  Unless I'm mistaken, this
> tells the debugger that there's no source lines in the function body,
> so "step" skips the function (since it operates on source-line level).

I've dug into this a bit further, after finally upgrading my 'gppnew'
installation to gcc-2.95.2, and I think I've got one step further in the
analysis of this particular case at least. There's new machine specific,
undocumented '-mschedule-prologue' switch that tells gcc how the function
prologue (maybe also epilogue) is to be generated. It can either be done
by a piece of RTL that is subject to optimization, along with the rest of
the code, or it can be output 'manually', in the final step when RTL is
transformed to the actual assembly. The default is to use RTL output, in
gcc-2.95.2. I have yet to find out when this change occured, and if the
problem coincides with that source change.

Compiling with '-g -O1 -mno-schedule-prologue' seemed to fix the problem.
To the extent that the problematic behaviour is limited to very short
functions (one or two lines of active source code), this would indicate
that the bug is in the new (?) RTL prologue and its handling regarding
line number information and optimization.

> If not, does this seem like a GCC bug or a GDB bug?  I want to know
> where to report this.

It's GCC bug, I'd say. You can clearly see the difference in the assembly
output from GCC. GDB is not to be blamed for reacting differently if the
input has changed. Furthermore, I got the exact same difference in the
assembly output when I tried to reproduce the problematic behaviour on x86
Linux, using gcc-2.95.2.

[...]
> This doesn't seem to be related to COFF vs stabs, 

Agreed. The .stabs symbols are at exactly the same locations, if you
-gstabs or -ggdb, as the .ln ones in -gcoff mode.

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -