User account creation filtered due to spam.

Bug 18459 - [4.0 Regression] gcj no longer works on win32
Summary: [4.0 Regression] gcj no longer works on win32
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
Keywords: patch, wrong-code
Depends on:
Blocks: 18107
  Show dependency treegraph
Reported: 2004-11-13 04:44 UTC by Rutger Ovidius
Modified: 2004-12-13 15:22 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2004-11-13 19:56:02


Note You need to log in before you can comment on or make changes to this bug.
Description Rutger Ovidius 2004-11-13 04:44:58 UTC
gcc version 4.0.0 20041113 (experimental)
I produce a cross compiler as I normally do.  Host is linux, target is
i686-pc-mingw32, and create a simple test class and compile:

public class test {
 public static void main(String[] sa) {
  System.out.println("H. World");

i686-pc-mingw32-gcj --main=test
Copy the a.exe to a win machine, run it, and it has an application error. All
.exe's that are created with gcj fail.

If I create a "hello world" test.c and compile it with i686-pc-mingw32-gcc, and
copy it to the win box it works fine.

The i686-pc-mingw32-gcj I built a month ago works without problem:
gcc version 4.0.0 20041014 (experimental)

Here is what I see in gdb:

(gdb) r
Starting program: /cygdrive/e/dev/test/a.exe

Program received signal SIGSEGV, Segmentation fault.
0x0043319d in _Jv_FindClass () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
67      /datal/gcc/gcc/gcc/config/i386/cygwin.asm: No such file or directory.
        in /datal/gcc/gcc/gcc/config/i386/cygwin.asm
Current language:  auto; currently asm
(gdb) bt
#0  0x0043319d in _Jv_FindClass () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#1  0x00401b27 in _Jv_FindClassFromSignature () at
#2  0x004333cd in _Jv_PrepareCompiledClass () at
#3  0x004095ad in java::lang::Class::initializeClass () at
#4  0x004096ed in java::lang::Class::initializeClass () at
#5  0x004096ed in java::lang::Class::initializeClass () at
#6  0x0040217c in _Jv_AllocObjectNoFinalizer () at
#7  0x00470e32 in java::util::Hashtable::entrySet () at
#8  0x004711ef in java::util::Hashtable::putAllInternal () at
#9  0x00470aa4 in java::util::Hashtable::clone () at
#10 0x00403cd4 in java::lang::System::__U3c_clinit__U3e_ () at
#11 0x0040954f in java::lang::Class::initializeClass () at
#12 0x00403702 in java::lang::System::getSecurityManager () at
#13 0x0040bba9 in java::lang::ClassLoader::getSystemClassLoader () at
#14 0x00433159 in _Jv_FindClass () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#15 0x00401b27 in _Jv_FindClassFromSignature () at
#16 0x004333cd in _Jv_PrepareCompiledClass () at
#17 0x004095ad in java::lang::Class::initializeClass () at
#18 0x0040217c in _Jv_AllocObjectNoFinalizer () at
#19 0x004021a7 in _Jv_AllocObject () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#20 0x00432b63 in _Jv_NewClass () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#21 0x004336d4 in _Jv_NewArrayClass () at
#22 0x00402432 in _Jv_NewObjectArray () at
#23 0x0046f8b2 in java::util::Hashtable::Hashtable () at
#24 0x0046fae2 in java::util::Hashtable::Hashtable () at
#25 0x004922dd in java::security::Permissions::finit$ () at
#26 0x0049230a in java::security::Permissions::Permissions () at
#27 0x0043d283 in java::lang::VMClassLoader::__U3c_clinit__U3e_ () at
#28 0x0040954f in java::lang::Class::initializeClass () at
#29 0x0043cef5 in java::lang::VMClassLoader::getSystemClassLoader () at
#30 0x0040c5d4 in java::lang::ClassLoader::__U3c_clinit__U3e_ () at
#31 0x0040954f in java::lang::Class::initializeClass () at
#32 0x00402ece in _Jv_CreateJavaVM () at
#33 0x004030c9 in _Jv_RunMain () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#34 0x0040329b in JvRunMain () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#35 0x004012ce in main (argc=1, argv=0x3d3e48)
Comment 1 Andrew Pinski 2004-11-13 05:35:23 UTC
This is the normal static linking "bug", aka PR 13708.

*** This bug has been marked as a duplicate of 13708 ***
Comment 2 Rutger Ovidius 2004-11-13 19:22:16 UTC
I don't think this is a duplicate - it has nothing to do with LANG settings.

The stacktrace may look similar, and end on _Jv_FindClass, but it does not go
through PrintStream/UnicodeToBytes.

I reverted the following patch to cygming.h from Nov 6th:

And everything works again.  
Comment 3 Andrew Pinski 2004-11-13 19:56:02 UTC
Hmm, then JCF sections are not support.
Comment 4 Danny Smith 2004-11-13 20:18:20 UTC
This excerpt from java/class.c appears relavant:
emit_register_classes (tree *list_p)
  if (registered_class == NULL)

  /* ??? This isn't quite the correct test.  We also have to know
     that the target is using gcc's crtbegin/crtend objects rather
     than the ones that come with the operating system.  */
  if (SUPPORTS_WEAK && targetm.have_named_sections)
      tree t;
      named_section_flags (JCR_SECTION_NAME, SECTION_WRITE);
      assemble_align (POINTER_SIZE);
      for (t = registered_class; t; t = TREE_CHAIN (t))
	assemble_integer (XEXP (DECL_RTL (t), 0),
      abort ();

mingw doesn't currently use crtbegin.o/crtend.o  -- nor any other mechanism to 
init __JCR_LIST__.

I am currently testing a patch (in conjunction with DW2 EH frame support) for 
this but will need about 2-3 days to go through a full bootstrap/reg-test cycle.

A safer option at this stage may be add another condition to disable for 

Comment 5 Rutger Ovidius 2004-11-14 19:34:47 UTC
Small followup:

Even though the hello world app works, a much larger app does not work (error:
app.exe is not a valid Win32 application.) unless I 'strip' it.  I'm not sure
why that would be...

(If that Dwarf2 EH patch makes stack traces work on win32, that should be a
really great improvement)
Comment 6 Andrew Pinski 2004-11-14 19:38:01 UTC
"error: app.exe is not a valid Win32 application" sounds like a binutils problem, I would report it to 
Comment 7 Rutger Ovidius 2004-11-14 20:25:31 UTC
I use binutils-2.15.91-20040904-1 from (latest I think).

I thought by removing the change to cygming.h this weak sym problem would be
gone, but I guess there are other changes somewhere that affect this.

Comment 8 Danny Smith 2004-11-25 21:40:08 UTC
Patch submitted at

In longer term, a better solution for win32 would depend on addition of 
crtbegin/crtend for these targets:

Comment 9 Rutger Ovidius 2004-12-10 03:11:25 UTC
I have tried this patch:
but a simple gcj --main=test -o test.exe ; test.exe just results in an
application error popup (on windows).

I have also tried ""
(with the 1 line binutils ld patch to add .jcr), but linking fails: undefined reference to `__gcj_personality_v0'

Removing the stuff from cygming.h and remaking my cross compiler makes things
work again.

i686-pc-mingw32-gcj (GCC) 4.0.0 20041209 (experimental)

public class test {
 public static void main(String[] a) {
Comment 10 Danny Smith 2004-12-10 10:09:56 UTC
Did you do a clean rebuild of libgcj.a after applying these patches?
Either works for me after native bootstrap on mingw32 host.  The second patch, 
however, does require CVS bunutils to get weak linkage to work correctly.


Comment 11 Rutger Ovidius 2004-12-10 16:35:53 UTC
It was a completely fresh checkout to an empty dir (both times). I build a
linux->win32 cross. (building on win32 takes way too long due to fork()).

For the dwarf2 patch, I had used the one line patch from:
on the binutils-2.15.91-20040904-1-src.tar.gz from  If I don't need
any further patches(?), I will try to use binutils directly from cvs and build
it again.

Comment 12 Danny Smith 2004-12-10 23:11:55 UTC
Ugh, I see what is wrong with the patch I posted at:

	* config/i386/cygming.h (TARGET_USE_JCR_SECTION): Overide

Index: gcc/gcc/config/i386/cygming.h
RCS file: /cvs/gcc/gcc/gcc/config/i386/cygming.h,v
retrieving revision 1.23
diff -c -3 -p -r1.23 cygming.h
*** gcc/gcc/config/i386/cygming.h	6 Nov 2004 04:28:06 -0000	1.23
--- gcc/gcc/config/i386/cygming.h	25 Nov 2004 21:25:17 -0000
*************** extern int i386_pe_dllimport_name_p (con
*** 408,413 ****
--- 410,420 ----
    while (0)
  #endif /* HAVE_GAS_WEAK */
+    but for .jcr section to work we also need crtbegin and crtend
+    objects  as well as linker supoort. */
+ #define USE_JCR_SECTION 0 <<<<<<
  /* Decide whether it is safe to use a local alias for a virtual function
     when constructing thunks.  */

That should be   

Sorry, I'll retest with clean CVS co and resubmit patch.

Comment 13 Rutger Ovidius 2004-12-12 17:40:39 UTC
I have rebuilt gcc a few times now, after modifying the patch to use #define
TARGET_USE_JCR_SECTION 0 and upgrading to a cvs version of binutils.

Using the first patch (
works, and small win32 binaries do run, but when I compile my large app (which
uses swt), it still isn't recognized as a win32 app (app.exe is not a valid
win32 application) unless I 'strip' it.  I don't know how to narrow down the
cause of this.  (binutils-041211)

I then tried out the second patch (dwarf)
( (leaving the first
patch still applied), along with Bryce's java stacktrace patch.  This worked for
me as well on a simple app.  On a larger app I still need to strip it, and
unfortunately swt uses callbacks, so the app receives a SIGSEGV when closing it:

Microsoft Visual C++ Runtime Library
Runtime Error!

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

(somewhere after _Java_org_eclipse_swt_internal_Callback_unbind -- gdb isn't
helpful since the app is stripped).

Patch comments (in the dwarf patch) mention a libgcc_s.dll being required in the
future? I am hoping that does not mean it would have to be included with every
gcj compiled .exe created for wide distribution since it would make apps less
self-contained on windows.

Anyone have hints on getting around this callback issue?  Bryce's stacktrace
patch is incredibly helpful with gcj-java compiled apps on win32.. pointers to
even a quick and dirty solution would be appreciated.
Comment 14 Danny Smith 2004-12-12 21:03:26 UTC
> small win32 binaries do run, but when I compile my large app (which
> uses swt), it still isn't recognized as a win32 app (app.exe is not a valid
> win32 application) unless I 'strip' it.  I don't know how to narrow down the
> cause of this.  (binutils-041211)

Why do you think this is related to this bug? With patch, the apps in libjava 
testsuite execute as valid win32 applications, as do the java utils built in 
libjava directory.  Maybe your problem is with linking to swt.dll?

Comment 15 Rutger Ovidius 2004-12-13 00:11:01 UTC
I don't know that it is related to the specific patch, I just know that when I
filed the general bug it was the time at which the app that I've been compiling
for a year suddenly stopped being recognized as a valid app on win32 until
'stripped' of symbols.  

The original problem was that all apps did not run (application error), due to
the weak symbols patch.  The secondary problem is that my app which I've been
compiling fine for a year and with a previous 4.0 version of gcc no longer is
recognized as a valid win32 .exe unless stripped.  

I'm not sure what else 'strip' does to the executable besides the removal of
symbols, so I'm not sure how to track down this problem yet.  Another generic
swt app works fine without being stripped, so I'm still at a loss on how to
target the problem.
Comment 16 CVS Commits 2004-12-13 08:35:29 UTC
Subject: Bug 18459

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	2004-12-13 08:35:16

Modified files:
	gcc            : ChangeLog 
	gcc/java       : ChangeLog 

Log message:
	PR target/18459
	Fix ChangeLog entry to refer to correct PR


Comment 17 Andrew Pinski 2004-12-13 15:22:35 UTC