Re: Answer
On March 31, 2002 04:06 pm, Carlos Andres Cañaveral Usuga wrote: I need work with jdbc for access to a database made on postgresql. It is posible with kaffe and how? thanks This is possible. I got it working once on an HP425 workstation (how's that for a Kaffe port?) I can't remember what, if anything, special was required. Simply build the JDBC module for PostGresQL and go!
Re: 1.0.5 install problem on FreeBSD
Archie Cobbs wrote: | | | David Jones writes: | Using the 1.0.5 release, on FreeBSD 3.0: | | main.c:362: Undefined symbol `_deadlockDetection' referenced from text segment | | The port builds fine for me.. are you using the port? Or CVS? I am using kaffe-1.0.5.tar.gz. | Did you rm -rf /usr/local/kaffe/include and /usr/local/lib/*kaffe* ? Neither exist. (I renamed /usr/local/lib/kaffe away and /usr/local/kaffe never existed.) In any event, having to do all this renaming makes an upgrade of a production machine impossible, so this is a serious problem.
Problems with Jitterbug
Andrew Pimlott wrote: | But it seems that I'm alone in the ``deep understanding'' of the | underlying assumptions of Jitterbug. I wonder if Andrew Tridgell and | Dan Shearer share this sensation with me... Or maybe it's I that just | don't get it, and the `Message type's are just a useless concept in | Jitterbug, that's going to be dropped in the next release... :-( | | Isn't it clear that the inability to search on two types (alternately, the | lack of a closed type) is a simple and obvious deficiency in jitterbug, | and that fixing it would a) take less time than this argument and b) make | everybody happy? GNATS uses a two-dimensional classification system: you have a category (util, io. lang, etc.) and a state (open, ignored, closed, etc.). GNATS is highly regimented in that state transitions are well-defined; Jitterbug is not. It seems that the fundamental problem here is that classification is really a 2D problem, and we are solving it with a 1D tool. (Note: I am not recommending that we move to GNATS. It's a beast.)
Re: Kaffe when blackdown in on.
Alex Turner wrote: | | On Sat, 1 May 1999, David Jones wrote: | | Alex Turner wrote: | | Also, has anyone got kaffe working with JDBC and Apache? | | I have Kaffe working with the PostgresQL JDBC driver, running on a Mentor | Graphics 425 workstation. | | | Brilliant, did it take much work, and how did you did it? 1. Get Kaffe working on the m68k. Follow Kiyo Inaba's instructions: get the latest version from CVS, and disable anything remotely resembling shared libraries or JIT. - Perform the regression tests, and make sure that Kaffe works solidly. 2. Get PostgresQL working on the m68k. There is a bug in the autoconf script that prevents Postgres from building correctly on the m68k. To fix, change the definition of PGRESULT_ALIGN_BOUNDARY in interfaces/libpq/fe-exec.c to read: #define PGRESULT_ALIGN_BOUNDARY 4 - Perform the PostgresQL regression tests and analyze. 3. Compile the JDBC driver that comes with PostgresQL. This driver has an incompatibility with Kaffe: it uses different implementations for JDK 1.1 and JDK 1.2/Java2. It auto-detects which JDK is in use by examining the value returned from the java.version property: if it starts with "1.1" then you have 1.1, else you have 1.2. Of course, Kaffe returns "1.0b4", Postgres tries to use the Java2 collection classes, and kaboom. You will need to hard-code 1.1 into jdbc/postgresql/Driver.java, as well as makeVersion.java. Once you try this, the Makefile that comes with PostgresQL should work fine. At this point, just follow the instructions that come with the JDBC driver. It "just worked". Quite slowly, since there is no working JIT for m68k, but it did work. It's important to make sure that Kaffe and PostgresQL work by themselves first, before trying the JDBC driver.
FreeBSD linking problem
I just built a recent snapshot on a FreeBSD system, which previously had a 1.0b3 snapshot installed. When linking Kaffe, I got hundreds of unresolved symbol errors. Many were to _enterUnsafeRegion and _leaveUnsafeRegion. The problem? Kaffe is linked using -lkaffevm, and libkaffevm is dynamic. So, ld searched my LD_LIBRARY_PATH for it. The old library, installed in /usr/local/lib, was hit first, and ld couldn't find the symbols. Choke. When I renamed /usr/local/lib/libkaffevm.so aside, the build proceeded correctly, since ld was forced to look further down its path to find the newly built libkaffevm.
m68k calling conventions (long/boring for non-m68k users)
I have installed Debian GNU/Linux on my Amiga 3000. That, along with NetBSD
on the HP425, allows me to compare Linux and NetBSD calling conventions.
Linux and NetBSD use different assembly language syntax. This is best
illustrated with the following C program:
double foo(double a)
{
return a * a + 1.0;
}
Under Linux, the resulting assembly code (gcc -S test.c) is:
.file "test.c"
.version"01.01"
gcc2_compiled.:
.text
.align 2
.globl foo
.typefoo,@function
foo:
link.w %a6,#0
fmove.d 8(%a6),%fp0
fmul.d 8(%a6),%fp0
fmovecr #0x32,%fp1
fadd.x %fp1,%fp0
unlk %a6
rts
.Lfe1:
.sizefoo,.Lfe1-foo
.ident "GCC: (GNU) 2.7.2.3"
Under NetBSD:
#NO_APP
gcc2_compiled.:
___gnu_compiled_c:
.text
.even
.globl _foo
.type_foo,@function
_foo:
link a6,#0
fmoved a6@(8),fp0
fmuld a6@(8),fp0
fmovecr #0x32,fp1
faddx fp0,fp1
fmoved fp1,sp@-
movel sp@+,d0
movel sp@+,d1
unlk a6
rts
Lfe1:
.size_foo,Lfe1-_foo
Some things to note:
1. NetBSD uses the "MIT syntax", whereas Linux uses a more traditional M68K
syntax. With the exception of the '%' before register names, the Linux
assembler conforms to the assembly language format used in the Motorola
manuals.
The NetBSD syntax must not use a '%' in register names, and the addressing
modes are written somewhat differently.
2. Linux returns floating point values in fp0. NetBSD uses d0/d1.
All this creates problems for us, of course. Kiyo has tried to unify
the sysdepCallMethod for Linux and NetBSD. Unfortunately, the differing
syntax makes this all but impossible. For this reason, I recommend that
trampolines.c and common.h be split into Linux- and NetBSD-specific versions,
each using the proper syntax. As well, a comment should be added to each
piece of code noting that it is the same as its counterpart except for the
syntax, and that any bug found in one segment of code must also be fixed
in its counterpart.
The next problem to resolve is how to return floating-point values.
Since Kaffe's JIT is not compatible at the moment with the C calling
conventions, we have the freedom to take a definitive decision. There are
two logical ways to proceed:
1. Use the OS native calling convention. This will require separate code
for Linux and NetBSD.
2. Pick a convention and use it throughout. This will impact one of the OSes,
in that some translation may be necessary.
There are two cases to consider: returning a value from Java code into Java
code, and returning a value from Java code into native code.
Returning into native code is accomplished by sysdepCallMethod(). Right now,
Kiyo has this OS-dependent (approach #1).
Returning into Java code is accomplished by returnarg_double(). Right now,
this works with the Linux calling convention only. There is only one
definition of define_insn(returnarg_double, ...) in jit-m68k.def, and it
refers only to fp0. The same code for the return_double code that picks
up the value from fp0 on the caller's side.
As it currently stands, the code will work only on Linux, because that is
the only system in which the two return methods are consistent.
I propose that we adopt the Linux convention of returning floating-point
results in fp0 throughout. I say this even though I'm a NetBSD bigot because
the Linux method is simply more efficient to a good JIT: the return value
is in a floating-point register, waiting for use without further ado.
Also, this requires no changes to the JIT itself. The only change required
is to sysdepCallMethod(), to always use fp0.
To summarize:
1. Re-write sysdepCallMethod() for m68k to always pick up floating point
results from fp0, and to not clobber registers.
2. Provide separate (syntax changes only) NetBSD and Linux versions of
all assembly code.
I am willing to do this for both NetBSD and Linux, testing on my 425 and
Amiga as appropriate. Are there any comments before I do so?
Re: -fPIC for m68k/netbsd
Kiyo Inaba wrote: | And also I noticed that binutils-2.9.1 derived 'as' on | m68k/netbsd can not handle '-k' flag at all. Did I make any | mistake, or is it the feature? Are you talking about the "as" that comes with NetBSD-1.3.1, or an aftermarket GAS install? The man page for as mentions -k. If you don't think it is working correctly, then send me a test case with expected resuts and I'll run it on my machine.
m68k calling conventions
I tried to rebuild the m68k port last night, after Kiyo's merging. First, I got some errors due to minor changes in the assembler syntax. I notice that some of the inline assembler code was changed to assemble under Linux. Why should the assembler syntax be different between Linux and NetBSD? Both systems use GAS, so the syntax will be the same. I will experiment with different syntaxes, to try to find one that works on both NetBSD and Linux. We are only asking for trouble if we have two versions of each assembly routine that differ only in their syntax. I may be able to get access to a Linux/m68k system to test this. Second, there appears to be a difference in the calling conventions between NetBSD and Linux in that a floating-point quantity is returned in d0/d1 on NetBSD but fp0 on Linux. Again, why? Kaffe's calling convention is NOT compatible with the standard C calling convention, because Kaffe does not respect callee-save registers. Rather, Kaffe assumes that all registers will be clobbered after a call to a function. For this reason, Kaffe cannot directly interwork with C functions. If it could, then this sysdepCallMethod stuff likely wouldn't be needed at all. Since we are not compatible with the C calling convention, we are free to use whatever convention we want. It makes sense to me in this case to use the same conventions on NetBSD as on Linux. To do otherwise simply creates unnecessary OS dependencies. Does anyone have any comments on this before I expend a lot of effort to make the code as simple as possible?
