Re: [PATCH] [4.5 regression] Fix PR42811: java.lang.ExceptionInInitializerError in ecj1 and associated issues.

[Andrew Haley <aph at redhat dot com>]

On 02/20/2010 06:36 PM, Dave Korn wrote:
> [ refs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
>         http://gcc.gnu.org/ml/java/2010-02/msg00002.html
>         http://gcc.gnu.org/ml/java/2010-02/threads.html#00004 ]
> 
>     Hi lists,
> 
>   The attached patches resolve PR42811 and the knock-on issues uncovered while
> fixing it (see refs).  I've separated them out for ease of review but I've
> tested them as a group and would like to ask the java maintainers whether they
> need to be applied separately or can all just go in as one.  Thanks are due to
> Hans and Bryce for their help in solving this one.
> 
>   The main PR is resolved by ensuring that both parts of the whole libgcj are
> always loaded, so that all the predefined class data from both sets of .jcr
> sections is always present at runtime.
> 
>   The uninitialised memory fix is straightforward and was already approved by
> Bryce in a separate thread, I quote it here for completeness, and with a
> slightly reworded changelog in case it needs to be applied separately from the
> fix for the main PR.
> 
>   The second copy of the gc code living in the -noncore sublibrary turned out
> very fortunately to be completely dead, only present because of
> --whole-archive; none of the -noncore code needed to link it at all, so there
> was no need to export it from the core sublibrary for the -noncore one to use.
>  Of course it was still a waste of time, memory and disk space, and it
> confused the hell out of gdb for some reason.  The same turned out to apply to
> the other convenience libs required by the main sublibrary, so I trivially
> removed them all.
> 
>   The changes to the boehm-gc are largely mechanical, and basically involve
> turning on the pseudo-support for DYNAMIC_LOADING that is implemented for the
> other windows hosts.  I simplified away the version checking, because cygwin
> never runs on any windows version that doesn't support DLLs (i.e. win32s), and
> it uses the unix get mem function so as to get memory from the cygwin
> allocator rather than allocating it from the windows api "behind cygwin's
> back"; apart from that, the usage of the VirtualQuery to determine memory
> ranges and properties will be absolutely fine on Cygwin, so I didn't try and
> rewrite it to use something based on mprotect() or whatever other posix api.
> 
> 
> pr42811-final.diff:
> libjava/ChangeLog:
> 
> 	PR java/42811
> 	* configure.ac (libgcj_spec_lgcj_override): Add undefined reference
> 	to arbitrary symbol in noncore library.
> 	(libgcj_spec_lgcj_bc_override): Likewise.
> 	configure: Regenerate.
> 
> pr42811-associated-uninitmem-fix.diff:
> libjava/ChangeLog:
> 
> 	* jvmti.cc (_Jv_GetJVMTIEnv): Avoid use of uninitialised memory.
> 
> pr42811-associated-dead-lib-code-link-fix.diff:
> libjava/ChangeLog:
> 
> 	* Makefile.am (libgcj_noncore_la_LIBADD): Don't include standard
> 	list of libtool convenience libs only needed by main library.
> 	* Makefile.in: Regenerate.
> 
> pr42811-associated-gc-fixes.diff:
> boehm-gc/ChangeLog:
> 
> 	* 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.
> 
> 
>   Bootstrapped and tested on i686-pc-cygwin; fixes PR42811 and doesn't cause
> any further regressions (there are some preexisting fails that this makes no
> difference to).  OK for head?

A couple of things:

1.  Bounce the gc changes off gc@napali.hpl.hp.com .
2.  Is it really necessary to make the main program depend on a symbol
    in libgcj-noncore when BC compiling?  Can't you make the libgcj
    itself depend on libgcj-noncore?

Andrew.