From owner-freebsd-amd64@FreeBSD.ORG Sun Jun 13 18:07:42 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFCBB16A4CE for ; Sun, 13 Jun 2004 18:07:42 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id C616643D48 for ; Sun, 13 Jun 2004 18:07:40 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 7D7E9FD03A for ; Sun, 13 Jun 2004 11:06:43 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26976-01 for ; Sun, 13 Jun 2004 11:06:43 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id E2ADAFD012 for ; Sun, 13 Jun 2004 11:06:42 -0700 (PDT) From: Sean McNeil To: freebsd-amd64@freebsd.org Content-Type: text/plain Message-Id: <1087150002.27523.12.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 13 Jun 2004 11:06:42 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: x86_64 ABI X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jun 2004 18:07:43 -0000 I am trying to get gcj/gij working and have it (for the most part) doing pretty well. I've noticed problems in backtraces of core dumps, however, that got me to wondering. The only documentation I've uncovered about the ABI was the stuff pointed to by the FreeBSD/amd64 web page. This looks like the same ABI that Linux is using. Are there any differences? Should the libffi native/jni calling interface used for Linux work for FreeBSD? Here is an example of a traceback I see that makes me wonder: #10 0x0000000200eeda2c in _Jv_NewPrimArray (eltype=0x2015b6698, count=16) at ./include/java-gc.h:55 #11 0x0000000200f8d0f1 in gnu.gcj.runtime.StringBuffer.StringBuffer(int) ( this=0x2059ee660, capacity=16) at ../../../gcc/libjava/gnu/gcj/runtime/StringBuffer.java:165 #12 0x0000000200f3547c in java.io.File.File(java.lang.String, java.lang.String) (this=0x202d5e320, dirPath=0x20416b020, name=0x2059fb000) at ../../../gcc/libjava/java/io/File.java:369 #13 0x0000000201021048 in ffi_call_UNIX64 () at /var/tmp/ccieZgQH.s:75 #14 0x0000000201020e4f in ffi_call (cif=0x202c4d658, fn=0x200f354d0 , rvalue=0x7ffffffef768, avalue=Variable "avalue" is not available. ) at ../../../gcc/libffi/src/x86/ffi64.c:564 #15 0x000000020102042c in ffi_java_raw_call (cif=0x202c4d658, fn=0x200f354d0 , rvalue=0x7ffffffef768, raw=Variable "raw" is not available. ) at ../../../gcc/libffi/src/java_raw_api.c:295 #16 0x0000000200f00b9a in _Jv_InterpMethod::run (this=0x202740ea0, retp=0x7ffffffef970, args=Variable "args" is not available. ) at ../../../gcc/libjava/interpret.cc:1166 #17 0x00000002010204a0 in ffi_java_translate_args (cif=0x20277f7c0, rvalue=0x7ffffffef970, avalue=0x7ffffffef920, user_data=0x20277f780) at ../../../gcc/libffi/src/java_raw_api.c:309 The part about the "is not available" is what bothers me. This is a bt with libc_r. The actual issue I'm dealing has to do with the boehm-gc garbage collector. I believe there may be a referenced pointer that is missed and it getting reaped by gc when it shouldn't. If there is a problem with libffi not storing things correctly or missing something, then that would explain it. I get a core dump at the same place with both libc_r and libpthread, so I feel it probably isn't a threading issue. Any help from the amd64 ABI gurus would be appreciated. Cheers, Sean