Mail Archives: djgpp-workers/2000/03/01/08:59:15
Hans-Bernhard Broeker wrote:
> 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?
It doesn't affect the involved variables.
> Have you checked the assembly
> listing?
No.
> 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.
That's not 100% correct, gdb can see values in registers, the problem is when gcc
moves the value from one register to another. It looks like this can't be modeled
with these debug information.
Is true that some of the back and forth is due to reordering and also because one
single line is split it more than one assembler chunck, but looks like the exact
line isn't recorded very well so you jump to places that aren't the exact place,
like jumping to the opening { of a function when in fact it should be to one line
above (initialization of the parent class) or other place.
So perhaps the problem is that 2.95 moves too much things and when trying to
record it some things gets wrong.
> > 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?
Yes. I understand why, but lines aren't accurate all the time.
> 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.
I can't reproduce these things with small programs! They are class constructors
of complex classes.
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
- Raw text -