This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

two egcs (gcc ?) bugs for you


Ok guys,

I have two yummy bugs for you.  I'm using egcs which puts this in the ELF
binary:  GCC: (GNU) egcs-2.90.27 980315 (egcs-1.0.2 release)
... on the intel x86 platform (linux; redhat 5.1.)  My colleagues with
newer versions of egcs reported the same problems.

The bugs (or anyway, one I'm sure is a bug and one I *think* is) surfaced
while programming an operating system kernel using egcs.

(1)  This is the *sure* bug ;).  I think it's a bug in the linker, though.
We could have made the entry point of the kernel in a separate assembler
file, but we decided to use the _start() function.  In our code, we did
just about:

void _start(void)
{
   asm("lgdtl (loadgdt)\n"
       /* ... etc */
      );

   /* some init stuff here */

   main();

   asm("cli;hlt");
}

You get the idea.  Also, the thing was linked with -Ttext 0x100000, and
entry.o (the file with _start()) was the first object file in our list.

This went fine with -O and -O2, but when we did either -O3, or
-finline-functions (which is implied by -O3 so the error must be caused
here) suddenly the linker placed main() at 0x100000, in stead of _start()
!!  This caused our computer, on trying to run it, to gallantly reboot.
Blah.

I'm not sure what caused this weird failure, but I'm willing to send you my
code if you want to check.


(2)  I'm not sure whether this is my mistake or not, but to me it looks
like a bug.

Defined was this:

extern long realtime;

void rttask1(void) {
	  int count;
	  for (count=1;;count++)
   {
		   print(count, 800+80);
     RTTASK1.time = realtime  +  606200;
		   quantumDone();
   }
}

long realtime is constantly changed by the timer interrupt.

This doesn't work like I had expected.  On examining the diassembly
produced with objdump, I noticed that the contents of realtime were loaded
into the register apparently alloted to it by egcs (%ebp,
-fomit-frame-pointer was also given) *outside* of the loop, while realtime
is actually accessed *inside* !  This means that RTTASK1.time was always
the same, realtime(0) + 606200 where realtime(0) is the value that realtime
had at the time it was loaded.  I was able to work around the problem by
defining long *rtptr = &realtime, and then using *rtptr in stead of
realtime, but it is still interesting that it doesn't work like I expected
it to.

I realise that in a standard unix process egcs's original code would have
sped it up quite a bit.  On the other hand, it quite ruins multithreaded
programs (imagine that this kind of thing happens when accessing
semaphores... whoa.)  Nowadays, you can't just expect programs are
single-threaded.

------

That was it.  I'll also give the exact options I compiled with:

egcs -O2 -fomit-frame-pointer -fno-builtin -m486 -I./include -nostartfiles
-nostdlib -nostdinc

and

ld -Ttext 0x100000

Hope these things will be fixed someday ;)

Ramon

PS if any of my bug-reports wasn't a bug, could you please inform me about
the matter ?  I'm quite convinced they're bugs, or I wouldn't have
submitted them, but if they aren't now's the time to learn some more C ;)

---
Ramon van Handel   <vhandel@chem.vu.nl>
Chemistry Student, OS Programmer and all-round Weirdo
"They could but make the best of it, and went around with woebegone faces
sadly complaining that on Mondays, Wednesdays, and Fridays they must look
on light as a wave;  on Tuesdays, Thursdays and Saturdays as a particle.  On
Sundays, they simply prayed."  -- Banesh Hoffmann, The Strange Story of
the Quantum




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]