[Bug java/18459] New: linux -> win cross compiler : gcj produces corrupt executables

[Bug java/18459] New: linux -> win cross compiler : gcj produces corrupt executables

[ovidr at users dot sourceforge dot net]

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 test.java
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
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#2  0x004333cd in _Jv_PrepareCompiledClass () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#3  0x004095ad in java::lang::Class::initializeClass () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#4  0x004096ed in java::lang::Class::initializeClass () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#5  0x004096ed in java::lang::Class::initializeClass () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#6  0x0040217c in _Jv_AllocObjectNoFinalizer () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#7  0x00470e32 in java::util::Hashtable::entrySet () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#8  0x004711ef in java::util::Hashtable::putAllInternal () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#9  0x00470aa4 in java::util::Hashtable::clone () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#10 0x00403cd4 in java::lang::System::__U3c_clinit__U3e_ () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#11 0x0040954f in java::lang::Class::initializeClass () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#12 0x00403702 in java::lang::System::getSecurityManager () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#13 0x0040bba9 in java::lang::ClassLoader::getSystemClassLoader () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#14 0x00433159 in _Jv_FindClass () at /datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#15 0x00401b27 in _Jv_FindClassFromSignature () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#16 0x004333cd in _Jv_PrepareCompiledClass () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#17 0x004095ad in java::lang::Class::initializeClass () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#18 0x0040217c in _Jv_AllocObjectNoFinalizer () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#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
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#22 0x00402432 in _Jv_NewObjectArray () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#23 0x0046f8b2 in java::util::Hashtable::Hashtable () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#24 0x0046fae2 in java::util::Hashtable::Hashtable () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#25 0x004922dd in java::security::Permissions::finit$ () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#26 0x0049230a in java::security::Permissions::Permissions () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#27 0x0043d283 in java::lang::VMClassLoader::__U3c_clinit__U3e_ () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#28 0x0040954f in java::lang::Class::initializeClass () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#29 0x0043cef5 in java::lang::VMClassLoader::getSystemClassLoader () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#30 0x0040c5d4 in java::lang::ClassLoader::__U3c_clinit__U3e_ () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#31 0x0040954f in java::lang::Class::initializeClass () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#32 0x00402ece in _Jv_CreateJavaVM () at
/datal/gcc/gcc/gcc/config/i386/cygwin.asm:67
#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)

-- 
           Summary: linux -> win cross compiler : gcj produces corrupt
                    executables
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ovidr at users dot sourceforge dot net
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug java/18459] linux -> win cross compiler : gcj produces corrupt executables

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-13 05:35 -------
This is the normal static linking "bug", aka PR 13708.

*** This bug has been marked as a duplicate of 13708 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug java/18459] linux -> win cross compiler : gcj produces corrupt executables

[ovidr at users dot sourceforge dot net]

------- Additional Comments From ovidr at users dot sourceforge dot net  2004-11-13 19:22 -------
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:

http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg00265.html

And everything works again.  

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-13 19:56 -------
Hmm, then JCF sections are not support.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|java                        |target
     Ever Confirmed|                            |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2004-11-13 19:56:02
               date|                            |
            Summary|linux -> win cross compiler |[4.0 Regression] gcj no
                   |: gcj produces corrupt      |longer works on win32
                   |executables                 |
   Target Milestone|---                         |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[dannysmith at users dot sourceforge dot net]

------- Additional Comments From dannysmith at users dot sourceforge dot net  2004-11-13 20:18 -------
This excerpt from java/class.c appears relavant:
void
emit_register_classes (tree *list_p)
{
  if (registered_class == NULL)
    return;

  /* ??? 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)
    {
#ifdef JCR_SECTION_NAME
      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),
			  POINTER_SIZE / BITS_PER_UNIT, POINTER_SIZE, 1);
#else
      abort ();
#endif


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 
cygwin/mingw 

Danny

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dannysmith at users dot
                   |                            |sourceforge dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[ovidr at users dot sourceforge dot net]

------- Additional Comments From ovidr at users dot sourceforge dot net  2004-11-14 19:34 -------
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)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-14 19:38 -------
"error: app.exe is not a valid Win32 application" sounds like a binutils problem, I would report it to 
them.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[ovidr at users dot sourceforge dot net]

------- Additional Comments From ovidr at users dot sourceforge dot net  2004-11-14 20:25 -------
I use binutils-2.15.91-20040904-1 from mingw.org (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.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[dannysmith at users dot sourceforge dot net]

------- Additional Comments From dannysmith at users dot sourceforge dot net  2004-11-25 21:40 -------
Patch submitted at 
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02192.html

In longer term, a better solution for win32 would depend on addition of 
crtbegin/crtend for these targets:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02120.html

Danny

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[ovidr at users dot sourceforge dot net]

------- Additional Comments From ovidr at users dot sourceforge dot net  2004-12-10 03:11 -------
I have tried this patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02192.html
but a simple gcj --main=test test.java -o test.exe ; test.exe just results in an
application error popup (on windows).

I have also tried "http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02120.html"
(with the 1 line binutils ld patch to add .jcr), but linking fails:
test.java: undefined reference to `__gcj_personality_v0'

Removing the stuff from cygming.h and remaking my cross compiler makes things
work again.
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/cygming.h.diff?cvsroot=gcc&r1=1.22&r2=1.23

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

public class test {
 public static void main(String[] a) {
  System.out.println("x");
 }    
}     

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[dannysmith at users dot sourceforge dot net]

------- Additional Comments From dannysmith at users dot sourceforge dot net  2004-12-10 10:09 -------
Rutger,
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.

Danny



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[ovidr at users dot sourceforge dot net]

------- Additional Comments From ovidr at users dot sourceforge dot net  2004-12-10 16:35 -------
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:
"http://sources.redhat.com/ml/binutils/2004-11/msg00249.html"
on the binutils-2.15.91-20040904-1-src.tar.gz from mingw.org.  If I don't need
any further patches(?), I will try to use binutils directly from cvs and build
it again.







-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[dannysmith at users dot sourceforge dot net]

------- Additional Comments From dannysmith at users dot sourceforge dot net  2004-12-10 23:11 -------
Ugh, I see what is wrong with the patch I posted at:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02192.html

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

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 */
  
+ /* FIXME: SUPPORTS_WEAK && TARGET_HAVE_NAMED_SECTIONS is true,
+    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.  */
  #undef TARGET_USE_LOCAL_THUNK_ALIAS_P

That should be   
#define TARGET_USE_JCR_SECTION 0

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

Danny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[ovidr at users dot sourceforge dot net]

------- Additional Comments From ovidr at users dot sourceforge dot net  2004-12-12 17:40 -------
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 (http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02192.html)
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)
(http://gcc.gnu.org/ml/gcc-patches/2004-11/msg02120.html) (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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[dannysmith at users dot sourceforge dot net]

------- Additional Comments From dannysmith at users dot sourceforge dot net  2004-12-12 21:03 -------
> 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?

Danny

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[ovidr at users dot sourceforge dot net]

------- Additional Comments From ovidr at users dot sourceforge dot net  2004-12-13 00:11 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-13 08:35 -------
Subject: Bug 18459

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	dannysmith@gcc.gnu.org	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
	http://gcc.gnu.org/ml/gcc-cvs/2004-12/msg00507.html

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6800&r2=2.6801
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&r1=1.1521&r2=1.1522



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459

[Bug target/18459] [4.0 Regression] gcj no longer works on win32

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-13 15:22 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459