[kaffe] Linux/x86 (GCC 4.1.1) and Cygwin
Dalibor Topic
robilad at kaffe.org
Wed Jul 5 17:28:17 PDT 2006
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?
More information about the kaffe
mailing list