Re: libjava test suite keeps getting stuck

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Zack" == Zack Weinberg <zackw@Stanford.EDU> writes:

Zack> There's a libtool bug and at least one libjava bug confusing the
Zack> issue.  The libtool bug: it links libgcc_s and libc ahead of
Zack> libpthread, which obviously will cause problems, because
Zack> libpthread won't get to override libc symbols.  I think this is
Zack> the transitive dependencies issue that was being discussed the
Zack> other week.

I thought Alexandre Oliva checked in a fix for this bug a while back.
This is the patch I'm thinking of:

2001-04-12  Alexandre Oliva  <aoliva@redhat.com>

        * ltconfig, ltmain.sh, libtool.m4, ltcf-c.sh, ltcf-cxx.sh,
        ltcf-gcj.sh: Upgraded to libtool 1.4a 1.641.2.226.

This fixed my problems with strange test results in libjava.

Maybe there is another problem that I haven't paid attention to?  :-(

Zack> My suggested fix for this is to stop using libtool.  :-)

This has come up a few times.  For the target libraries the argument
is that since we know we're using gcc we could just have gcc do the
work.

That would be fine by me but I thought there were other reasons that
made this not as easy as it looks.  I defer to Alexandre on shared
library issues.  (Mostly I find I don't want to know about the
horribleness of it all.)

Zack> The immediate libjava bug: if I take the test case I'm currently
Zack> looking at (Divide_1, from the libjava test suite) and get rid of the
Zack> explicit -lgcc_s -lc -lgcc_s, then the program prints

I've never seen that :-(
What platform is this?

I use x86 Red Hat Linux 6.2.  I bootstrap with /usr/bin/gcc.  I get 0
FAIL from check-target-libjava.

Zack> That exception should have been caught inside Divide_1::probe.
Zack> All the operations which divide by zero (which this program
Zack> does, deliberately) are wrapped in try/catch clauses.

To me this sounds like some sort of problem with throwing exceptions
from signal handlers.

Zack> #6  0x404c1c4c in uw_frame_state_for (context=0xbfee95f4, fs=0xbfee9534)
Zack>     at ../../../gcc_vanilla/gcc/unwind-dw2.c:966

Oh, wait -- this is the trunk!  I think you didn't mention that.

Throwing exceptions from signal handlers is known to be broken on the
trunk.  The new EH work didn't include a fix to libjava to keep this
working.

I believe Andrew is going to look at this problem (he is the Java EH
expert), but he is on vacation.

Jim Wilson proposed disabling Java on the trunk for the time being.
That's ok with me as long as we can turn it on again once this problem
is resolved.

Tom