X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Tue, 29 Feb 2000 15:07:06 +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: <38BBC78A.B416715E@inti.gov.ar> 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 Tue, 29 Feb 2000, salvador wrote: > 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. This jumping back and forth, in and of itself, does not mean anything is broken. During the optimization steps, the compiler may reorder statements in a way that makes the debugger step back and forth in the source code. This did not happen regularly in x86 code, before, but if you ever step through highly optimized code on a RISC machine, or an Alpha CPU, you get used to this behaviour. I think gcc-2.95 just optimizes things more strongly than any of the predecessors, including aggressive reordering of single instructions which may allow the CPU to carry out several operations in parallel. To really check this, there is no other way than to look at the assembly source code generated by the compiler. You may want to use -fverbose-asm, and maybe the -Wa,-alhs or similar swiches, to get a complete listing. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.