[Bug target/18459] [4.0 Regression] gcj no longer works on win32
--- 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: [EMAIL PROTECTED] 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=gccr1=2.6800r2=2.6801 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1521r2=1.1522 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18459
[Bug target/18459] [4.0 Regression] gcj no longer works on win32
--- 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
[Bug target/18459] [4.0 Regression] gcj no longer works on win32
--- 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
--- 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
--- 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
--- 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
--- 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 - 1.23 --- gcc/gcc/config/i386/cygming.h 25 Nov 2004 21:25:17 - *** 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
--- 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
--- 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=gccr1=1.22r2=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
--- 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
--- 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
--- 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
--- 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
--- 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|-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
--- 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
