linking executables with -Wl,--whole-archive libgcj-noncore.la libgcj.la -Wl,--no-whole-archive solves this problem. excepts that it creates fatty import symbol table approx. (28 megabyte). is there any workaround instead of this naive method?

Created attachment 19671 [details]
patch

now it summons gcj-noncore dll and resolves classes which should have been resolved. i know it's not perfect. so i need your revision.

(In reply to comment #2)
> Created an attachment (id=19671) [edit]
> patch
> 
> now it summons gcj-noncore dll and resolves classes which should have been
> resolved. i know it's not perfect. so i need your revision.

Thanks for this analysis, I think you're right, the classes provided in the noncore dll need to be present and there aren't always linker dependencies to bring them in.  I'll try and figure a way to do it automatically using static dependencies.

Created attachment 19808 [details]
proposed fix

I'm going to bootstrap and test this patch, which adds a dummy static dependency to pull in the noncore library everywhere.

Created attachment 19928 [details]
patch respin

So, after much single-stepping in the debugger, and some discussion on the mailing list:

http://gcc.gnu.org/ml/java/2010-02/msg00002.html
http://gcc.gnu.org/ml/java/2010-02/threads.html#00004

Here is the patch that I'm now testing.  It appeared to resolve the TestEarlyGC failure after a quick rebuild in a dirty $objdir, but it needs a full bootstrap/test cycle to be sure; results will be in tomorrow.

Created attachment 19977 [details]
Alternative approach

This alternative approach attempts to place a circular dependency between the two generated DLLs by linking into the core library a pseudo-import library specially generated before the real -noncore import library is built.  Gonna take it for a bootstrap and test cycle tonight.

Raising priority P4 -> P3 and Cc'ing RM.

I didn't want to ask to block the release for a bug in a long-neglected language on a secondary target before I was sure I'd be able to come up with a fix in time, but now that I have a good fix that has been tested, addresses all the comments raised in initial reviews, accepted upstream in the relevant parts, and is just waiting approval, I'd like to make sure it goes in before you branch; I see we're down to about half-a-dozen P1s now.

Final version of the patch posted at:

http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00931.html

Java is not release critical.  If it doesn't make 4.5.0 it can easily make 4.5.1.

Right you are.  I'll just have to hope it gets approved quickly while those remaining P1s gradually tick away... :)

Recategorising; "target" narrowly wins out over "libjava".  Patch was approved at http://gcc.gnu.org/ml/java-patches/2010-q1/msg00062.html

Subject: Bug 42811

Author: davek
Date: Sun Mar 21 19:34:19 2010
New Revision: 157604

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157604
Log:
	PR target/42811 (prerequisite)
	* include/private/gc_priv.h (struct roots) [CYGWIN32]: Don't
	declare r_next member on Cygwin as on other windows hosts.
	(LOG_RT_SIZE) [CYGWIN32]: Don't define likewise.
	(RT_SIZE) [CYGWIN32]: Likewise.
	(struct _GC_arrays) [CYGWIN32]: Do declare _heap_bases[] member
	likewise.
	(GC_heap_bases) [CYGWIN32]: Do define likewise.
	(struct _SYSTEM_INFO) [CYGWIN32]: Do forward-declare likewise.
	(GC_sysinfo) [CYGWIN32]: Do declare extern likewise.
	(GC_n_heap_bases) [CYGWIN32]: Likewise.
	(GC_is_tmp_root) [CYGWIN32]: Do prototype likewise.
	* include/private/gcconfig.h (GC_win32_get_mem) [CYGWIN32]: Likewise.
	(GET_MEM) [CYGWIN32]: Do define likewise.
	* boehm-gc/ptr_chck.c (GC_is_visible) [CYGWIN32]: Do handle dynamic
	registration likewise.
	* boehm-gc/os_dep.c (GC_setpagesize) [CYGWIN32]: Do define likewise.
	(GC_no_win32_dlls) [CYGWIN32]: Define as constant false, unlike
	other windows hosts.
	(GC_sysinfo) [CYGWIN32]: Define as on other windows hosts.
	(GC_n_heap_bases) [CYGWIN32]: Likewise.
	(GLOBAL_ALLOC_TEST) [CYGWIN32]: Likewise.
	(GC_win32_get_mem) [CYGWIN32]: Likewise, but wrapping GC_unix_get_mem
	rather than GlobalAlloc/VirtualAlloc.
	(GC_win32_free_heap) [CYGWIN32]: Likewise, but wrapping free instead
	of GlobalFree (even though the function body is optimised away).
	* boehm-gc/mark_rts.c (add_roots_to_index) [CYGWIN32]: Define as on
	other windows hosts.
	(GC_add_roots_inner) [CYGWIN32]: Avoid overlapping or adjacent
	intervals likewise.
	(GC_clear_roots) [CYGWIN32]: Clear GC_root_index[] likewise.
	(GC_rebuild_root_index) [CYGWIN32]: Define as on other windows hosts.
	(GC_remove_tmp_roots) [CYGWIN32]: Call it likewise.
	(GC_remove_roots) [CYGWIN32]: Don't define, as on other windows hosts.
	(GC_is_tmp_root) [CYGWIN32]: Define, as on other windows hosts.
	(GC_cond_register_dynamic_libraries) [CYGWIN32]: Handle temporary
	roots and dynamic registration likewise.
	* boehm-gc/dyn_load.c (GC_has_static_roots) [CYGWIN32]: Define as on
	other windows hosts.
	(GC_register_has_static_roots_callback) [CYGWIN32]: Likewise.
	(GC_cond_add_roots) [CYGWIN32]: Likewise.
	(GC_register_main_static_data) [CYGWIN32]: Define to always return
	false, as on MSWINCE
	(HAVE_REGISTER_MAIN_STATIC_DATA) [CYGWIN32]: Define as on other
	windows hosts.
	(GC_warn_fb) [CYGWIN32]: Likewise.
	(GC_disallow_ignore_fb) [CYGWIN32]: Likewise.
	(GC_ignore_fb_mb) [CYGWIN32]: Likewise.
	(GC_ignore_fb) [CYGWIN32]: Likewise.
	(is_frame_buffer) [CYGWIN32]: Likewise.
	(GC_dump_meminfo) [CYGWIN32]: Likewise.
	(GC_wnt) [CYGWIN32]: Define to constant true.
	(GC_register_dynamic_libraries) [CYGWIN32]: Define as on other
	windows hosts.


Modified:
    trunk/boehm-gc/ChangeLog
    trunk/boehm-gc/dyn_load.c
    trunk/boehm-gc/include/private/gc_priv.h
    trunk/boehm-gc/include/private/gcconfig.h
    trunk/boehm-gc/mark_rts.c
    trunk/boehm-gc/os_dep.c
    trunk/boehm-gc/ptr_chck.c

Subject: Bug 42811

Author: davek
Date: Sun Mar 21 19:36:49 2010
New Revision: 157605

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157605
Log:
	PR target/42811 (prerequisite)
	* jvmti.cc (_Jv_GetJVMTIEnv): Avoid use of uninitialised memory.


Modified:
    trunk/libjava/ChangeLog
    trunk/libjava/jvmti.cc

Subject: Bug 42811

Author: davek
Date: Sun Mar 21 19:41:37 2010
New Revision: 157606

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157606
Log:
	PR target/42811
	* libjava/configure.ac (DLLTOOL): Call AC_CHECK_TOOL.
	(libgcj_sublib_core_extra_deps): New host-dependent configure var.
	(LIBGCJ_SUBLIB_CORE_EXTRA_DEPS): AC_SUBST it.
	* libjava/configure.host (libgcj_sublib_core_extra_deps): Define
	appropriately on Cygwin and MinGW.
	(libgcj_sublib_core_extra_deps): Add libgcj-noncore-dummy import
	stub library on Cygwin and MinGW.
	* libjava/Makefile.am (LIBJAVA_CORE_EXTRA): Import AC_SUBST'd
	LIBGCJ_SUBLIB_CORE_EXTRA_DEPS if building sublibs, else define empty.
	(libgcj_la_DEPENDENCIES): Use it.
	(DLL_VERSION): New makefile macro.
	(libgcj-noncore-dummy.dll.a): New build rule for dummy import stub
	library.
	(libgcj_noncore_la_LIBADD): Trim superfluous convenience libs.
	(AM_MAKEFLAGS): Add DLLTOOL recursive propagation.
	* libjava/libgcj-noncore-dummy.def: New file.
	* libjava/Makefile.in: Regenerate.
	* libjava/include/Makefile.in: Likewise.
	* libjava/testsuite/Makefile.in: Likewise.
	* libjava/configure: Likewise.
	* libjava/gcj/Makefile.in: Likewise.


Added:
    trunk/libjava/libgcj-noncore-dummy.def
Modified:
    trunk/libjava/ChangeLog
    trunk/libjava/Makefile.am
    trunk/libjava/Makefile.in
    trunk/libjava/configure
    trunk/libjava/configure.ac
    trunk/libjava/configure.host
    trunk/libjava/gcj/Makefile.in
    trunk/libjava/include/Makefile.in
    trunk/libjava/testsuite/Makefile.in

And another one bites the dust.

Subject: Bug 42811

Author: davek
Date: Thu May  6 16:20:53 2010
New Revision: 159115

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159115
Log:
	PR target/42811
	* tests/staticrootstest.c: New test source file.
	* tests/staticrootslib.c: New test library source file.
	* Makefile.am (test_ldadd): New variable.
	(gctest_LDADD): Use it.
	(TESTS): Add leaktest, middletest and staticrootstest.
	(check_PROGRAMS): Likewise.
	(leaktest_SOURCES): New libtool variable definition.
	(leaktest_LDADD): Likewise.
	(leaktest_LDFLAGS): Likewise.
	(leaktest_LINK): Likewise.
	(middletest_SOURCES): Likewise.
	(middletest_LDADD): Likewise.
	(middletest_LDFLAGS): Likewise.
	(middletest_LINK): Likewise.
	(staticrootstest_SOURCES): Likewise.
	(staticrootstest_LDADD): Likewise.
	(staticrootstest_LDFLAGS): Likewise.
	(staticrootstest_LINK): Likewise.
	(check_LTLIBRARIES): Likewise.
	(libstaticrootslib_la_SOURCES): Likewise.
	(libstaticrootslib_la_LIBADD): Likewise.
	(libstaticrootslib_la_LDFLAGS): Likewise.
	(libstaticrootslib_la_DEPENDENCIES): Likewise.
	* Makefile.in: Regenerate.


Added:
    trunk/boehm-gc/tests/staticrootslib.c
    trunk/boehm-gc/tests/staticrootstest.c
Modified:
    trunk/boehm-gc/ChangeLog
    trunk/boehm-gc/Makefile.am
    trunk/boehm-gc/Makefile.in

On alphaev68-pc-linux-gnu, I'm getting:

make[4]: Entering directory `/space/uros/gcc-build/alphaev68-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Completed 3 tests
Allocated 5687484 collectable objects
Allocated 306 uncollectable objects
Allocated 3749022 atomic objects
Allocated 34440 stubborn objects
Finalized 6617/6617 objects - finalization is probably ok
Total number of bytes allocated is 228541040
Final heap size is 11345920 bytes
Collector appears to work
Completed 322 collections
PASS: gctest
Leaked composite object at 0x200002cdee0 (../../../gcc-svn/trunk/boehm-gc/tests/leak_test.c:16, sz=8, NORMAL)

FAIL: leaktest
Final heap size is 131072
PASS: middletest
PASS: staticrootstest
===================
1 of 4 tests failed
===================
make[4]: *** [check-TESTS] Error 1

Is this failure something to worry about?

(In reply to comment #16)
> On alphaev68-pc-linux-gnu, I'm getting:
> FAIL: leaktest

> 1 of 4 tests failed

> Is this failure something to worry about?
 
The honest answer is: I can't tell you.  These are test cases that come with the boehm-gc itself, that have previously been disabled in the gcc import, now I re-enabled them.  You won't be suffering from any problem that you didn't already suffer from, in particular w.r.t the use of boehm-gc in libjava, but while it's possible this is a false positive dependent on the precise details of the platform, it's also possible this points to a real unfixed bug.  I don't know of any way to tell without really getting down into debugging the internals of the GC to see why it's complaining.

But, it's only a new failure because the test didn't used to be run before at all.  You're definitely no worse off than you used to be; just now, you know it.

FYI, the same failure happens on x86_64-pc-linux-gnu, but is silent for some reason:

gmake[4]: Entering directory `/home/uros/gcc-build/x86_64-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Completed 3 tests
Allocated 5705175 collectable objects
Allocated 306 uncollectable objects
Allocated 3750000 atomic objects
Allocated 34440 stubborn objects
Finalized 6679/6679 objects - finalization is probably ok
Total number of bytes allocated is 327875152
Final heap size is 22253568 bytes
Collector appears to work
Completed 384 collections
PASS: gctest
Leaked composite object at 0x2b5d6f749ef0 (../../../gcc-svn/trunk/boehm-gc/tests/leak_test.c:16, sz=8, NORMAL)

PASS: leaktest
Final heap size is 131072
PASS: middletest
PASS: staticrootstest
==================
All 4 tests passed
==================

(In reply to comment #18)
> FYI, the same failure happens on x86_64-pc-linux-gnu, but is silent for some
> reason:

> Leaked composite object at 0x2b5d6f749ef0
> (../../../gcc-svn/trunk/boehm-gc/tests/leak_test.c:16, sz=8, NORMAL)
> 
> PASS: leaktest
> Final heap size is 131072

No, as far as I can see it's OK and that's a successful PASS.  The purpose of the test is to leak some memory and verify that the GC can *detect* the leak.

As indeed it does in the other case as well, which now makes me suspect that the alpha FAIL is probably a false negative.  The test code is rather old, declares main as an implict int function, and doesn't have a return statement in it.  That could easily end up returning some random register contents as an exit status.  Do you have time to check if adding a "return 0;" at the end of the main() function resolves the failure?

(In reply to comment #19)

> As indeed it does in the other case as well, which now makes me suspect that
> the alpha FAIL is probably a false negative.  The test code is rather old,
> declares main as an implict int function, and doesn't have a return statement
> in it.  That could easily end up returning some random register contents as an
> exit status.  Do you have time to check if adding a "return 0;" at the end of
> the main() function resolves the failure?

Yeah, adding "return 0;" fixes the failure!

Created attachment 20652 [details]
GC testsuite fixes

Patch that declares "int main" and adds "return 0;" to the tests.

Hm, I'm not able to run thread_test.c and thread_leak_test.c tests using "make -k check", so otherwise deadly trivial patch can't be fully tested.

(In reply to comment #22)
> Hm, I'm not able to run thread_test.c and thread_leak_test.c tests using "make
> -k check", so otherwise deadly trivial patch can't be fully tested.
> 

Well I can't approve it but I think it's as close to "obvious" as anything gets.  If you send it to libjava-patches (and cc the upstream list for boehm-gc: <gc@napali.hpl.hp.com> - we're trying to avoid any divergence), I can't imagine anyone would object.  Thanks for helping track this down :)

(In reply to comment #23)

> Well I can't approve it but I think it's as close to "obvious" as anything
> gets.  If you send it to libjava-patches (and cc the upstream list for
> boehm-gc: <gc@napali.hpl.hp.com> - we're trying to avoid any divergence), I
> can't imagine anyone would object.  Thanks for helping track this down :)

OK, patch sent and committed to SVN gcc.