This is the mail archive of the gcc@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]

Re: continuing egcs-1.1 problems


On Sat, 31 Oct 1998, David Edelsohn wrote:

> >>>>> Amal Phadke writes:
> 
> >> --- egcs-1.0.2-min.s    Fri Oct 30 22:14:05 1998
> >> +++ egcs-1.1b-min.s     Fri Oct 30 22:18:50 1998
> >> 
> >> main:
> >> -       mr 12,1
> >> -       addi 1,1,-112
> >> -       stw 12,0(1)
> >> +       stwu 1,-112(1)
> >>	   mflr 0
> 
> 	These two versions are performing the same operation and the
> latter one actually is more correct because it is updating the stack
> pointer atomically.  This is part of a function prologue.  When compiling
> egcs-1.1b, this pattern is used throughout and it obviously is working in
> order to compile this test.
> 
> 	Are you sure that this is not a problem in glibc?  Are both
> egcs-1.0.2 and egcs-1.1b using the same "fixed" include files?  Either one
> of the other differences you omit or glibc is the source of the problem.
> 

First, I'll tell you what I've done this morning.  I took the egcs-1.0.2
SRPM from DR3 and unpacked it.  This contained a number of patches from
Gary Thomas.  It then started comparing the contents of the patches with
the current egcs-1.1b distribution.  I selected the patches which had not
been incorporated into the distribution, and I applied those to egcs-1.1b.
Then I built this patched version of egcs-1.1b and ran my little test
case.  This time it worked!

I have no idea which of these patches was the critical piece.  The names
of the patch files were

 egcs-1.1b-ppc_mcount.patch
 egcs-1.1b-ppc_noupdate.patch
 egcs-1.1b-ppc_trampoline.patch
 
One or more of these solved the problem.  

The mcount patch seems to be fairly innocuous.  Gary seems to have renamed
_mcount to __mcount in the profiling code so that you couldn't
accidentally mix profiling code from earlier libraries with the current
compiler.  According to his notes, the profiling method changed so he
wanted to prevent a conflict.  (A very crude paraphrase of his note.) 

The noupdate patch causes the compiler to not generate a stwu op code.
This can be confirmed by looking at the output from gcc -S.

The trampoline patch fixes a couple of problems with verifying the size of
the stack and keeping the stack aligned.  My best guess is that this is
the critical patch, but I haven't confirmed it.  Someone with a little
patience needs to rebuild egcs with these patches one at a time to see
which one really fixes the problem.  Frankly, I've built egcs five times
in the last 36 hours, and I'm sick of the sight of it. :-)

For what it is worth, I packaged up the (putatively) working egcs-1.1b
code and uploaded it to ftp://ftp.linuxppc.org/incoming.  Source and
binary rpms were placed there.  If someone wants to investigate further,
they are welcome to do so. :-)

The difference between the now working code and the code generated by the
unpatched egcs:

[bacon@bacon bacon]$diff egcs-1.1b-min.s egcs-1.1b-patched-min.s
8c8,10
<       stwu 1,-112(1)
---
>       mr 12,1
>       la 1,-112(1)
>       stw 12,0(1)
17d18
<       crxor 6,6,6
26c27
< .L1:
---
> .L13:          

Personally, I think that mysterious 666 is to blame.  Happy Halloween! :-)

(Couldn't ask for a better exit line.)

Fred Bacon

==========================================================================
Aerodyne Research, Inc.                   Phone:   (978) 663-9500 ext. 273
45 Manning Rd.                              FAX:   (978) 663-4918
Billerica, MA  01821-3976                  http://www.aerodyne.com
==========================================================================
    Life is a tragedy for those who feel and a comedy for those who think.





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