Date: Sun, 27 Feb 2000 09:41:43 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Hans-Bernhard Broeker cc: 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 Thanks for the feedback. On Thu, 24 Feb 2000, Hans-Bernhard Broeker wrote: > My first guess: the new optimizer might have inlined the whole thing into > so small a piece of assembly that there is no useful division into > function dfunc(), func() and sqrt() left. I don't see any such extreme optimizations. It looks like a compiler bug, unless I'm missing something. See below. > 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 double dfunc (double a) { return a * sqrt (a); } gcc -g -O0 gcc -g -O --------------------------------------------------------- .globl _dfunc .globl _dfunc _dfunc: _dfunc: pushl %ebp .ln 2 movl %esp,%ebp pushl %ebp subl $8,%esp movl %esp,%ebp .ln 2 subl $8,%esp addl $-8,%esp fldl 8(%ebp) fldl 8(%ebp) fsqrt subl $8,%esp fucom %st(0) fstpl (%esp) fnstsw %ax call _sqrt andb $69,%ah addl $16,%esp cmpb $64,%ah fmull 8(%ebp) je L3 jmp L2 fstp %st(0) .ln 3 addl $-8,%esp .p2align 4,,7 pushl 12(%ebp) L2: pushl 8(%ebp) movl %ebp,%esp call _sqrt popl %ebp L3: ret fmull 8(%ebp) movl %ebp,%esp popl %ebp ret .ln 3 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). Am I missing something? If not, does this seem like a GCC bug or a GDB bug? I want to know where to report this. > I had noticed that there was > a discrepency in the way line-number based debug information was handled > by the BFD library, between COFF and .stabs symbols. This doesn't seem to be related to COFF vs stabs, since compiling with -gstabsN has the same problem for all levels of N up to 3; only -gstabs+ somehow manages to convince the debugger that there are some source lines in dfunc. I don't know enough about stabs to see something interesting in comparison of the output of -gstabs3 and -gstabs+. > At that time, Robert Hoehne told me that GDB has its own code to handle > the mapping between line numbers and code addresses. That's true. > It just might be > that since then, the new ports of GCC, GDB and/or binutils have broken > this GDB code in a way similar to how BFD version 2.8.1 was broken. I don't think so: this bug shows in both GDB 4.18 and a recent snapshot of the upcoming GDB 5. If there *is* a GDB bug here, I think it was there for quite some time.