On Tue, 2006-07-04 at 12:41 +0900, Kazuyuki Shudo wrote: > Hi all, > > I could succeessfully compile Kaffe with GCC 4.1.1 and it seems to run > correctly on Linux/x86. The platform is the development version toward > Fedora Core 6. > Hi Kazuyuki,
thank you for the patch. I've been working on a similar patch for the past days, and I've checked it in now. Could you give it a try and see if CVS head works ok for you, as well? > With the patch, we can also build and run Kaffe on Cygwin. Note that > GTK+ in the current Cygwin is not new enough to support GTK peers of > Kaffe. The configure script requires the --disable-gtk-peer option. Cool, thank you for giving Kaffe a go on Cygwin. Judging by your patches, I assume you built the jit engine rather than the interpreter engine. Do both have the same regression test failures under make check? > On Cygwin, Kaffe can be compiled but it is not very stable. Small > programs run but medium-scale ones will not. Additionally, Jikes has > to be patched. Jikes 1.22 tweaks inode values returned by Cygwin but > the tweak is harmful today. Yeah, the jikes 1.22 package in Cygwin lacks a patch, that's necessary to be able to build the class library. If you have some time, please take a look at FAQ/FAQ.win32 and send in a patch to bring it up to date with your experiences. > With GCC 4.1.1 on Linux/x86, the most serious problem was the return > value of __builtin_frame_address(0). The intrinsic function of GCC > 4.1.1 returns %ebp - 12, not the very value of %ebp. This behaviour > seems to be specific to the argument 0. The argument 1 is also proper > for Kaffe and works fine. Thanks for the good news! I've talked with gcc hacker Andrew Pinski about the change in __builtin_frame_address between gcc versions, and his opinion was that we really shouldn't be using it for things other than debugging gcc, if I recall our IRC conversation correctly. I've noticed that other projects, notably Mozilla, had a similar issue with gcc 4.1. See http://developer.mozilla.org/en/docs/Building_on_Fedora_Core_5#No_stack_traces_due_to___builtin_frame_address.280.29_malfunction for what they did. They ended up using a single line of assembler to access the frame pointer, so that's what my patch ended up doing as well. > The patch is not well sorted out and it contains over 10 tweaks and > printf lines for debugging. I hope someone digests the patch and > incorporates the changes into Kaffe. Thank you for sending in a patch! I've got some comments and questions below to some part of the patch. cheers, dalibor topic > plain text document attachment (kaffe-20060627.patch) > --- ./libraries/javalib/external/classpath/java/io/PrintStream.java.orig > 2006-04-03 09:51:03.000000000 +0900 > +++ ./libraries/javalib/external/classpath/java/io/PrintStream.java > 2006-07-02 20:43:43.000000000 +0900 > @@ -117,12 +117,17 @@ > try { > this.encoding = SystemProperties.getProperty("file.encoding"); > } catch (SecurityException e){ > - this.encoding = "ISO8859_1"; > + this.encoding = "ISO_8859_1"; > } catch (IllegalArgumentException e){ > - this.encoding = "ISO8859_1"; > + this.encoding = "ISO_8859_1"; > } catch (NullPointerException e){ > - this.encoding = "ISO8859_1"; > + this.encoding = "ISO_8859_1"; > } > + > + if (this.encoding == null) { > + this.encoding = "ISO_8859_1"; > + } > + > this.auto_flush = auto_flush; > } > > --- > ./libraries/javalib/external/classpath/gnu/classpath/SystemProperties.java.orig > 2006-04-18 22:32:58.000000000 +0900 > +++ > ./libraries/javalib/external/classpath/gnu/classpath/SystemProperties.java > 2006-07-02 20:43:43.000000000 +0900 > @@ -66,6 +66,9 @@ > > static > { > + // temporally set > + properties = defaultProperties; > + > VMSystemProperties.preInit(defaultProperties); > > defaultProperties.put("gnu.classpath.home", > Configuration.CLASSPATH_HOME); > @@ -104,7 +107,7 @@ > > // 8859_1 is a safe default encoding to use when not explicitly set > if (defaultProperties.get("file.encoding") == null) > - defaultProperties.put("file.encoding", "8859_1"); > + defaultProperties.put("file.encoding", "ISO_8859_1"); > > // XXX FIXME - Temp hack for old systems that set the wrong property > if (defaultProperties.get("java.io.tmpdir") == null) this seems to be done to fix an encoding problem, right? > --- ./config/i386/cygwin32/jit-md.h.orig 2006-07-03 13:08:32.000000000 > +0900 > +++ ./config/i386/cygwin32/jit-md.h 2006-07-03 13:10:16.000000000 +0900 > @@ -25,10 +25,10 @@ > * No signal handler support yet!! > */ > #define EXCEPTIONPROTO > \ > - int sig > + int sig, siginfo_t *ctx, void *uc0 > > #define EXCEPTIONFRAME(f, c) > \ > (f).retbp = 0; \ > - (f).retpc = 0 > + (f).retpc = c->si_addr + 1 > > #endif > --- ./config/i386/cygwin32/md.h.orig 2006-07-03 13:08:29.000000000 +0900 > +++ ./config/i386/cygwin32/md.h 2006-07-03 13:09:26.000000000 +0900 > @@ -31,8 +31,8 @@ > #undef SP_OFFSET > #define SP_OFFSET 7 > > -#define SIGNAL_ARGS(sig, sc) int sig > -#define SIGNAL_CONTEXT_POINTER(scp) int scp > +#define SIGNAL_ARGS(sig, sc) int sig, siginfo_t *sc, void *uc0 > +#define SIGNAL_CONTEXT_POINTER(scp) siginfo_t **scp > #define GET_SIGNAL_CONTEXT_POINTER(sc) (NULL) > #define SIGNAL_PC(scp) (0) > > --- ./config/i386/trampolines.S.orig 2005-09-14 20:53:16.000000000 +0900 > +++ ./config/i386/trampolines.S 2006-07-02 20:43:43.000000000 +0900 > @@ -39,7 +39,7 @@ > popl %eax > push %ebp > mov %esp,%ebp > -#if defined(PIC) > +#if defined(PIC) && !defined(__CYGWIN__) > pushl %ebx > call .L2 > .L2: ah, great! I assume this fixed the jit (build) on Cygwin? > --- ./kaffe/kaffevm/jit/stackTrace-impl.h.orig 2006-07-03 > 13:12:32.000000000 +0900 > +++ ./kaffe/kaffevm/jit/stackTrace-impl.h 2006-07-03 13:51:51.000000000 > +0900 > @@ -8,6 +8,14 @@ > struct _exceptionFrame* frame; > } stackTrace; > > +#ifdef __CYGWIN__ > +#define STACKTRACEINIT(S, I, O, R) \ > + { \ > + FIRSTFRAME((S).nframe, O); \ > + (S).frame = &((S).nframe); \ > + (R) = *(S).frame; \ > + } > +#else Could you elaborate on what this change does? > --- ./kaffe/kaffevm/systems/unix-pthreads/signal.c.orig 2006-04-16 > 16:20:16.000000000 +0900 > +++ ./kaffe/kaffevm/systems/unix-pthreads/signal.c 2006-07-03 > 13:12:16.000000000 +0900 > @@ -457,7 +457,12 @@ > > if (JTHREAD_SETJMP(outOfLoop) == 0) > { > +#ifdef __CYGWIN__ > + /* getpagesize() of Cygwin 1.5.19-4 returns 0x10000, not 0x1000 */ > + uintp pageSize = 0x1000; > +#else > uintp pageSize = getpagesize(); > +#endif So the getpagesize implementation returns a wrong value? Is that still the case with cygwin dll 1.5.20 ? > --- ./kaffe/kaffevm/systems/unix-pthreads/thread-impl.c.orig 2006-05-25 > 00:58:25.000000000 +0900 > +++ ./kaffe/kaffevm/systems/unix-pthreads/thread-impl.c 2006-07-02 > 20:43:43.000000000 +0900 > @@ -451,7 +451,7 @@ > > if (SIGRTMAX - SIGRTMIN < 7) > { > -#if defined(OLD_LINUXTHREADS) > +#if defined(OLD_LINUXTHREADS) && !defined(__CYGWIN__) > sigSuspend = SIGURG; > sigResume = SIGTSTP; > sigDump = SIGXCPU; > @@ -474,8 +474,7 @@ I assume they're getting ifdefed out since those SIGs don't exist on Cygwin? > --- ./kaffe/kaffevm/exception.c.orig 2006-07-03 13:26:13.000000000 +0900 > +++ ./kaffe/kaffevm/exception.c 2006-07-03 13:26:52.000000000 +0900 > @@ -94,7 +94,9 @@ > { > assert(eh != NULL); > assert(eh->meth == VMEXCEPTHANDLER_KAFFEJNI_HANDLER); > +#ifndef __CYGWIN__ > assert(fp != (JNIFrameAddress)0); > +#endif > > return (eh->frame.jni.fp == fp); > } is the assert really Cygwin specific? _______________________________________________ kaffe mailing list [email protected] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
