cffi-devel

cffi-devel@common-lisp.net

1113 discussions

Start a nNew thread

Re: [cffi-devel] Crashes on X86-64 CLISP
by Hoehle, Joerg-Cyril 03 Feb '06

03 Feb '06

1 0

Re: [cffi-devel] Crashes on X86-64 CLISP
by Hoehle, Joerg-Cyril 03 Feb '06

03 Feb '06

James Bielman wrote: >By the way, I was looking into writing a regression test for this and >had problems since we also use FOREIGN-ADDRESS-UNSIGNED to implement >POINTER-EQ. Could we be using EQUALP instead for comparing pointers >(or is the fact that seems to work just a coincidence?) I was considering adding pointer-eq to the FFI, since even with 32bit, the current cffi:pointer-eq implementation is likely to cons bignums. So far, every null-pointer test conses a bignum, just to test against 0. The irony of history is that, the FFI once had FFI:NULL-POINTER-P (sp?). It was deprecated when the FFI was reviewed to consistently return NIL for NULL. Later, I added unsigned-foreign-address. After some thought, I decided I'd let it create a #<pointer> object from 0, instead of returning NIL. I thought, "if people really want to obtain a pointer with address 0 using this low-level function, let them do it". Nowadays, CFFI uses these presumably low-level primitives a lot. I.e. the useage pattern differs between programs using FFI and CFFI. The fact that there's an exception to the NIL<->NULL rule means that robust code implementing cffi:NULL-POINTER-P must test both cases, causing duplication of work (and so far, consing). Solutions: A Reintroduce ffi:null-pointer-p, not consing. B Change unsigned-foreign-address to return NIL instead of #<foreign-address #x0000000>. There would be (almost?) no more exception, and null-pointer-p would become equivalent to cl:NULL. C Implement cffi:null-pointer-p via cl:NULL and don't worry about somebody asking for (unsigned-foreign-address 0) returning something else. It might work in practice. There's just the one CFFI testcase (null-pointer-p (make-pointer 0)) (oh, it's been removed). Comments? I'm considering A+B, together with pointer-eq. Jorg Hohle.

1 0

Re: [cffi-devel] Crashes on X86-64 CLISP
by Hoehle, Joerg-Cyril 03 Feb '06

03 Feb '06

James Bielman wrote: >It looks like the problem is with FFI:UNSIGNED-FOREIGN-ADDRESS and >FFI:FOREIGN-ADDRESS-UNSIGNED expecting and returning 32-bit integers: And it's me who wrote this bogus code :-( :-( If you can recompile CLISP yourself, go to the 2 functions in src/foreign.d and change UL_to_I to UQ_to_I and I_to_UL to I_to_UQ And I'm going to push a patch to CVS. Regards, Jorg Hohle.

2 1

AW: [cffi-devel] Crashes on X86-64 CLISP
by Hoehle, Joerg-Cyril 03 Feb '06

03 Feb '06

James Bielman wrote: >> What if you run the stepper in interpreted mode? >I'm not entirely sure how to try this---I'll read the documentation >tomorrow and give this a shot. (asdf:oos 'asdf:load-source-op :cffi) (step (test-struct.5)) Or (step (with-foreign-object...)) >> What if you call (ffi:memory-as *the-s-s-ch* ffi:uint8/char/...) >> directly? >That seems to work Uhoh, then it's likely not the FFI. Please investigate. FWIW, in clisp you obtain the disassembly via (sys::disassemble-closures (lambda () (declare (compile)) (with-foreign-object (s 's5) (setf (foreign-slot-value s 's5 'a) 42) (foreign-slot-value s 's5 'a))) t) Regards, Jorg Hohle.

2 1

Re: [cffi-devel] Crashes on X86-64 CLISP
by Hoehle, Joerg-Cyril 03 Feb '06

03 Feb '06

James, >I don't know if anyone has tested CFFI on an X86-64 CLISP, but the >following tests crash with an unexpected segfault: I'm in the process of modifying the ffcall/FFI, but so far I've only planned to modify long-long support. I'm not aware of anything else not yet in the bugtracker. Do you have access to an -64 machine or was that a user report? > STRUCT.ALIGNMENT.1 This is quite surprising, since it dereferences a single byte. There should be no problems with alignment with byte-oriented access. Does this machine pass the clisp testsuite (ffi.tst)? >so far I haven't found anything yet. What if you run the stepper in interpreted mode? Does the crash happen exactly within a call to ffi:MEMORY-AS or elsewhere? This test doesn't seem to do anything else. Does it actually invoke (ffi:memory-as address 'ffi:uint8 0) Or (ffi:memory-as address 'character 0)? What if you call (ffi:memory-as (address-of *the-s-s-ch*) 'ffi:uint8/char/...) directly? Regards, Jorg Hohle.

2 1

[cffi-devel] New patches: 2-Feb-2006
by loliveira＠common-lisp.net 03 Feb '06

03 Feb '06

Thu Feb 2 19:30:09 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Remove documentation string from test type. M ./tests/misc-types.lisp -2 +2 Thu Feb 2 19:12:13 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Add ERRORP keyword argument to FOREIGN-ENUM-VALUE / FOREIGN-ENUM-KEYWORD. - If ERRORP is false, converting nonexistent enum values and keywords will return NIL instead of signalling an error. M ./src/enum.lisp -10 +12 Thu Feb 2 18:41:28 CST 2006 James Bielman <jamesjb(a)jamesjb.com> * Add an optimization for defining non-translatable types. - New generic function on types: TRANSLATE-P. This is true for all types except built-in foreign types and typedefs defined non-translatable. - Incompatible change: DEFCTYPE now accepts keyword arguments :TRANSLATE-P and :DOCUMENTATION instead of an optional docstring. - Define the standard integers types as non-translatable. M ./src/early-types.lisp -1 +18 M ./src/functions.lisp -3 +3 M ./src/types.lisp -25 +25 Thu Feb 2 06:49:08 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Evaluate define-foreign-librare earlier for CMUCL Since we're wrapping use-foreign-library with an eval-when to load foreign library at compile-time, we need to do the samething with define-foreign-library otherwise use-foreign-library will try to load an undefined library. M ./src/libraries.lisp -1 +1 Thu Feb 2 06:47:53 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Implement defbitfield - New macros and functions: DEFBITFIELD, FOREIGN-BITFIELD-VALUE, FOREIGN-BITFIELD-SYMBOLS. M ./TODO +2 M ./src/enum.lisp -9 +87 M ./src/package.lisp +3 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060202.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

[cffi-devel] Crashes on X86-64 CLISP
by James Bielman 03 Feb '06

03 Feb '06

Hi, I don't know if anyone has tested CFFI on an X86-64 CLISP, but the following tests crash with an unexpected segfault: DEREF.ARRAY-OF-AGGREGATES STRUCT.ALIGNMENT.1 STRUCT.ALIGNMENT.2 STRUCT.ALIGNMENT.3 STRUCT.ALIGNMENT.4 STRUCT.ALIGNMENT.5 STRUCT.ALIGNMENT.6 STRUCT.ALIGNMENT.7 STRUCT.NESTED-SETF I'll see if I can figure out what's going on here, but so far I haven't found anything yet. James

1 0

Re: [cffi-devel] must cffi-sys::with-pointer-to-vector-data go?
by Hoehle, Joerg-Cyril 02 Feb '06

02 Feb '06

Hi, there's an IMHO compelling reason why with-pointer-to-vector-data CANNOT be implemented using copying. As a result, the shareable vector API must be provided as a strictly optional, API on implementations that support it. The API's service would then merely be unification of various vendor APIs, a valuable goal for CFFI. The reason is as follows: Sharing produces problems similar to those of multiprocessor machines with separate caches. AFAIK, the 68060 processor can sniff the bus while "idle" and invalidate (or possibly reload) its cache. CFFI cannot do this. Trying to copy in one or the other direction does not implement sharing. It instead implements "with exclusive access from Lisp (resp. foreign) side within the scope of the body" -- depending on the direction of the copying. Here's a testcase. Try to imagine the following within the body of a macro that surrounds it with copying the block in one direction or the other. (setq/defparameter shared-array (make-shareable-byte-vector 2000)) (fill shared-array 2) (with-pointer-to-vector-data (ptr shared-array) (loop for i below (length shared-array) when (oddp i) do (setf (aref shared-array i) (mod i 256)) else do (setf (mem-aref ptr :ubyte i) 17))) ;2nd loop to verify result on shared-array not shown, but trivial. So what's the feature's name? #+cffi-feature:shareable-vector #+cffi-feature:shared-vector Regards, Jorg Hohle.

2 1

[cffi-devel] anaphora-devel vs cffi-devel confusion
by Nikodemus Siivola 02 Feb '06

02 Feb '06

There seems to be some sort of confusion with the cffi and anaphora mailing lists: I get the cffi emails with a subject line starting "[anaphora-devel]", and I'm also getting subscription notifications for cffi-devel as if they were for anaphora-devel. (I'm subscribed to cffi-devel, but definitely not the list owner, or even admin.) Is anyone else seeing this? Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."

2 1

[cffi-devel] New patches: 1-Feb-2006
by loliveira＠common-lisp.net 02 Feb '06

02 Feb '06

Wed Feb 1 21:57:29 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Fix allegro's %load-foreign-library Versions prior to 7.0 don't have a :foreign keyword argument for LOAD. Reported by Andrew Philpot. M ./src/cffi-allegro.lisp -1 +2 Wed Feb 1 13:17:12 CST 2006 Luis Oliveira <loliveira(a)common-lisp.net> * Make defcenum accept duplicate values. DEFCENUM will discard the previous value->keyword mapping (though not the respective keyword->value mapping of course) when it find a duplicate value. M ./src/enum.lisp -4 +5 Wed Feb 1 06:40:58 CST 2006 keriax(a)gmail.com * Add check for FreeBSD and remove some redundant assignments. M ./tests/Makefile -18 +9 An updated tarball of CFFI's source can be downloaded here: http://common-lisp.net/project/cffi/tarballs/cffi-060201.tar.gz Darcsweb URL: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cffi;a=summary

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

cffi-devel