Current gcj on powerpc

[Mark Wielaard]

Hi,

On Sun, 2002-08-04 at 01:04, Bryce McKinlay wrote:
> Mark Wielaard wrote:
> >
> >Thanks, of course the compiler optimizes the assignment away since it is
> >never used. But now that I can print it it doesn't make sense:
> >
> >    110	  abort();
> >    (gdb) print code
> >    $1 = 268705696
> >
> >Which doesn't make sense since only value 0 till 8 are meaningfull
> >according to unwind.h. Sigh.
> >
> 
> It might be worth adding a printf ("Unwind code: %i\n", code) or 
> whatever in exception.cc just to be sure that the assignment isn't being 
> done properly even though optimization isn't used.

Did that and it prints the same value.

> >I have been readding the patch is parts and it seems that the DSA
> >provider classes are to blame (I can add all other changes and new
> >classes without problem). But compiling on my powerpc machine is very
> >slow so it might take a while till I have found out exactly which of the
> >following classes causes this strange behaviour:

OK after to many (slow) recompiles I finally found a pattern. It seems
that it is related to the number of classes or the size of the shared
library. When I remove some classes (gnu/java/locale has a couple that
can be safely removed) then I can suddenly add all the provider classes
and make the testsuite run OK. Nasty. The libgcj.so.3.0.0 is > 26M
(unstripped) on my powerpc.

I quickly tried to add a few extra classes from classpath to libgcj
(java/util/logging/prefs/regex...) to see if I could get the same issue
on my x86 machine but everything seems to keep working on that platform.

If it is an size issue, what would be the best approach to get to the
bottom of this?

Good night,

Mark