delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2000/02/27/02:52:57

Date: Sun, 27 Feb 2000 09:41:43 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Debugging difficulties with GCC 2.95.2
In-Reply-To: <Pine.OSF.4.10.10002241638020.8670-100000@acaxp6.physik.rwth-aachen.de>
Message-ID: <Pine.SUN.3.91.1000227093924.14604A-100000@is>
MIME-Version: 1.0
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

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019