Mail Archives: djgpp-workers/2000/02/27/02:52:57
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.
- Raw text -