From: pavenis AT lanet DOT lv
To: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Date: Tue, 27 Mar 2001 10:02:07 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: gcc2953 and RHIDE debugging
Cc: djgpp-workers AT delorie DOT com
Message-ID: <3AC0651F.20684.C1391@localhost>
References: <3ABF8AC0 DOT 12369 DOT 55D5DE AT localhost>
In-reply-to: <Pine.LNX.4.10.10103261910140.15931-100000@acp3bf>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Reply-To: djgpp-workers AT delorie DOT com

On 26 Mar 2001, at 19:16, Hans-Bernhard Broeker wrote:

> On Mon, 26 Mar 2001 pavenis AT lanet DOT lv wrote:
> 
> > On 26 Mar 2001, at 13:46, Hans-Bernhard Broeker wrote:
> 
> > For example I compiled some source with gcc-2.95.3 using options 
> > '-gcoff -O2 -c' and run objdump -debug on .o file. Below is fragment
> > of output related to main ()
> 
> That objdump output looks rather strange to me. Is this a new format 
> introduced with binutils 2.10, perhaps?

I used binutils-2.11rc1 (binutils-2.9.1 doesn't fix the problem)

It seems that origin of problem is that the end line of previous 
procedure is used and it's undefined at the start of the first one
in each source file. gcc-3.0 20010314 (prerelease) uses line number at 
start of procedure and seems to be Ok. So only the first procedure
per source file is affected.

> 
> I'm especially puzzled since none of the code lines you show in those
> objdumps contains any executable code at all (only un-initialized strictly
> local variables).
> 
> > It seems clearly to be GCC problem. 
> > 
> > A test for simple "Hello World" style program:
> > 
> > #include <iostream>
> > 
> > int main (void)
> > {
> >   std::cout << "Hello\n";
> >   return 0;
> > }
> > 
> > I'm getting following diffs between assembler outputs
> > 
> > --- hello.s.2.95.2	Mon Mar 26 15:00:36 2001
> > +++ hello.s.2.95.3	Mon Mar 26 14:59:56 2001
> > @@ -207,25 +207,25 @@
> >  .globl _main
> >  _main:
> >  LFB1:
> > -	.def	.bf;	.val	.;	.scl	101;	.line	4;	.endef
> > -	.ln	2
> > +	.def	.bf;	.val	.;	.scl	101;	.line	0;	.endef
> >  	pushl %ebp
> >  LCFI0:
> >  	movl %esp,%ebp
> >  LCFI1:
> >  	subl $8,%esp
> >  LCFI2:
> > +	.ln	1
> 
> Up to here, this looks exactly like the error that exists since 2.95 or
> so, and which can be avoid by -mno-schedule-prologue.
> 
> > So it really would be nice to compare on some other system. Linux is 
> > not usable for this test (doesn't support -gcoff) and I cannot use 
> > MINGW port of GCC (I only have gcc-2.95.2)
> 
> OK, I'll try to build a gcc-2.95.3 on that Alpha box, then. But not
> before tomorrow.

It would be Ok. 

Andris