[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