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 X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com Subject: Re: Debugging difficulties with GCC 2.95.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.