X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Tue, 29 Feb 2000 20:33:32 +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: <38BC18F3.360641B7@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: > Hans-Bernhard Broeker wrote: > > 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. > > I agree, but that is not the case! the code isn't ejecuted during the > first "pass", but in the second. How would you know it's not executed? Have you checked the assembly listing? Or followed changes to register contents? When a C instruction is broken into several parts by the optimizer's instruction reordering phase, intermediate results will be in registers, rather than in the actual variables. I.e. gdb may not see them, at all. > And also: is not just another order, you get the impression the code > is ejecuted twice. What's the difference you base this distinction on? If you step through a two-line function, and gdb shows line numbers 1 2 1 2 in that order, what makes this look like the function being executed twice, instead of parts of lines one and two having been mixed with each other, on assembly level? If you still don't believe this, show me a small example case, together with its assembly listing ('gcc -gstabs3+ -S' output, or a '-g -Wa,-alhs' listing), so we can see what it's actually doing. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.