Sender: root AT delorie DOT com Message-ID: <38BD1825.54BC8BCF@inti.gov.ar> Date: Wed, 01 Mar 2000 10:16:21 -0300 From: salvador Organization: INTI X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.38 i686) X-Accept-Language: es-AR, en, es MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: Debugging difficulties with GCC 2.95.2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com 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