here is the scenario:
(defpackage :lispverse (:use :common-lisp :cffi))
(in-package :lispverse)
(define-foreign-library libverse (:unix (:or "/home/deepfire/source/% EXTRN/uni-verse/=src/verse/libverse.so")) (t (:default "libverse"))) (use-foreign-library libverse)
(let ((foreign-ptr (foreign-symbol-pointer "verse_send_connect_accept" :code))) (format t "foreign-ptr contents: ") (dotimes (i 16) (format t "~2,'0X " (the (unsigned-byte 8) (mem-ref foreign-ptr :uint8 i)))) (format t "~%"))
This code gives different printouts on CLISP/CMUCL/SBCL backends:
CLISP: foreign-ptr contents: 55 89 E5 83 EC 28 8B 45 0C 89 44 24 04 8D 45 F8 CMUCL: foreign-ptr contents: E9 26 AE C3 F9 90 00 00 00 00 00 00 00 00 00 00 SBCL: foreign-ptr contents: E9 CE A2 A1 47 90 00 00 00 00 00 00 00 00 00 00
This amounts to foreign-symbol-pointer finding different things on different lisps, in the same shared library.
The CLISP way appears to be correct, according to objdump:
0001a43b <verse_send_connect_accept>: 1a43b: 55 push %ebp 1a43c: 89 e5 mov %esp,%ebp 1a43e: 83 ec 28 sub $0x28,%esp 1a441: 8b 45 0c mov 0xc(%ebp),%eax 1a444: 89 44 24 04 mov %eax,0x4(%esp) 1a448: 8d 45 f8 lea 0xfffffff8(%ebp),%eax 1a44b: 89 04 24 mov %eax,(%esp) ...
libverse.so is attached.
regards, Samium Gromoff
On Tue, 2006-04-11 at 01:55 +0400, Samium Gromoff wrote:
here is the scenario:
[snip]
(let ((foreign-ptr (foreign-symbol-pointer "verse_send_connect_accept" :code))) (format t "foreign-ptr contents: ") (dotimes (i 16) (format t "~2,'0X " (the (unsigned-byte 8) (mem-ref foreign-ptr :uint8 i)))) (format t "~%"))
This code gives different printouts on CLISP/CMUCL/SBCL backends:
CLISP: foreign-ptr contents: 55 89 E5 83 EC 28 8B 45 0C 89 44 24 04 8D 45 F8 CMUCL: foreign-ptr contents: E9 26 AE C3 F9 90 00 00 00 00 00 00 00 00 00 00 SBCL: foreign-ptr contents: E9 CE A2 A1 47 90 00 00 00 00 00 00 00 00 00 00
This amounts to foreign-symbol-pointer finding different things on different lisps, in the same shared library.
Luis Olivera suggested using (foreign-symbol-pointer ... :data) instead of (foreign-symbol-pointer ... :code), and it worked just fine, now providing pointers to exactly same code!
Apparently in the CMU/SBCL case i`ve been fed pointers to proc linkage table entries or some lisp-specific trampolines.
respectfully, Samium Gromoff
On Tue, 11 Apr 2006 02:42:19 +0400, Samium Gromoff _deepfire@mail.ru said:
Delivered-To: cffi-devel@common-lisp.net
On Tue, 2006-04-11 at 01:55 +0400, Samium Gromoff wrote:
here is the scenario:
[snip]
(let ((foreign-ptr (foreign-symbol-pointer "verse_send_connect_accept" :code))) (format t "foreign-ptr contents: ") (dotimes (i 16) (format t "~2,'0X " (the (unsigned-byte 8) (mem-ref foreign-ptr :uint8 i)))) (format t "~%"))
This code gives different printouts on CLISP/CMUCL/SBCL backends:
CLISP: foreign-ptr contents: 55 89 E5 83 EC 28 8B 45 0C 89 44 24 04 8D 45 F8 CMUCL: foreign-ptr contents: E9 26 AE C3 F9 90 00 00 00 00 00 00 00 00 00 00 SBCL: foreign-ptr contents: E9 CE A2 A1 47 90 00 00 00 00 00 00 00 00 00 00
This amounts to foreign-symbol-pointer finding different things on different lisps, in the same shared library.
Luis Olivera suggested using (foreign-symbol-pointer ... :data) instead of (foreign-symbol-pointer ... :code), and it worked just fine, now providing pointers to exactly same code!
Apparently in the CMU/SBCL case i`ve been fed pointers to proc linkage table entries or some lisp-specific trampolines.
Is there any problem with getting different code? Using :data for code is not portable.
__Martin
On Tue, 2006-04-11 at 10:30 +0100, Martin Simmons wrote:
On Tue, 11 Apr 2006 02:42:19 +0400, Samium Gromoff _deepfire@mail.ru said:
Delivered-To: cffi-devel@common-lisp.net
On Tue, 2006-04-11 at 01:55 +0400, Samium Gromoff wrote:
here is the scenario:
[snip]
(let ((foreign-ptr (foreign-symbol-pointer "verse_send_connect_accept" :code))) (format t "foreign-ptr contents: ") (dotimes (i 16) (format t "~2,'0X " (the (unsigned-byte 8) (mem-ref foreign-ptr :uint8 i)))) (format t "~%"))
This code gives different printouts on CLISP/CMUCL/SBCL backends:
CLISP: foreign-ptr contents: 55 89 E5 83 EC 28 8B 45 0C 89 44 24 04 8D 45 F8 CMUCL: foreign-ptr contents: E9 26 AE C3 F9 90 00 00 00 00 00 00 00 00 00 00 SBCL: foreign-ptr contents: E9 CE A2 A1 47 90 00 00 00 00 00 00 00 00 00 00
This amounts to foreign-symbol-pointer finding different things on different lisps, in the same shared library.
Luis Olivera suggested using (foreign-symbol-pointer ... :data) instead of (foreign-symbol-pointer ... :code), and it worked just fine, now providing pointers to exactly same code!
Apparently in the CMU/SBCL case i`ve been fed pointers to proc linkage table entries or some lisp-specific trampolines.
Is there any problem with getting different code? Using :data for code is not portable.
Indeed -- sometimes the C code wants to be fed back pointers to its own functions. As markers for setting up callbacks, for example.
Also, i guess, the principle of least astonishment is applicable here -- that is, a pointer to the function is a pointer to the function, after all.
regards, Samium Gromoff
On Tue, 11 Apr 2006 23:28:08 +0400, Samium Gromoff _deepfire@mail.ru said:
On Tue, 2006-04-11 at 10:30 +0100, Martin Simmons wrote:
> On Tue, 11 Apr 2006 02:42:19 +0400, Samium Gromoff _deepfire@mail.ru said:
Delivered-To: cffi-devel@common-lisp.net
On Tue, 2006-04-11 at 01:55 +0400, Samium Gromoff wrote:
here is the scenario:
[snip]
(let ((foreign-ptr (foreign-symbol-pointer "verse_send_connect_accept" :code))) (format t "foreign-ptr contents: ") (dotimes (i 16) (format t "~2,'0X " (the (unsigned-byte 8) (mem-ref foreign-ptr :uint8 i)))) (format t "~%"))
This code gives different printouts on CLISP/CMUCL/SBCL backends:
CLISP: foreign-ptr contents: 55 89 E5 83 EC 28 8B 45 0C 89 44 24 04 8D 45 F8 CMUCL: foreign-ptr contents: E9 26 AE C3 F9 90 00 00 00 00 00 00 00 00 00 00 SBCL: foreign-ptr contents: E9 CE A2 A1 47 90 00 00 00 00 00 00 00 00 00 00
This amounts to foreign-symbol-pointer finding different things on different lisps, in the same shared library.
Luis Olivera suggested using (foreign-symbol-pointer ... :data) instead of (foreign-symbol-pointer ... :code), and it worked just fine, now providing pointers to exactly same code!
Apparently in the CMU/SBCL case i`ve been fed pointers to proc linkage table entries or some lisp-specific trampolines.
Is there any problem with getting different code? Using :data for code is not portable.
Indeed -- sometimes the C code wants to be fed back pointers to its own functions. As markers for setting up callbacks, for example.
Also, i guess, the principle of least astonishment is applicable here -- that is, a pointer to the function is a pointer to the function, after all.
OK, I see. Beware that on some OSes, functions can have an internal entrypoint and multiple external entrypoints, so different modules can see different pointers to the same function even in C code. This should be OK for function pointer comparison as long as the the old and new values are read by the same module.
__Martin
-
Martin Simmons -
Samium Gromoff