Hi Michael,
I've just tried to run PSI with php-master (32-bit DEBUG build) and got SIGSEGV
on the simplest test.
Use "psi.d/string.psi" and attemt to call psi\strerror(10)
#0 0xf44916ba in psi_call_frame_parse_args (frame=0xf426c500,
execute_data=0x0) at /home/dmitry/php/ext-psi/src/call.c:273
#1 0xf4494fe7 in psi_context_call (C=0x92dfe90, execute_data=0x0,
return_value=0x8fc0144 <HARDCODED_INI+4>, impl=0x9341658)
at /home/dmitry/php/ext-psi/src/context.c:250
#2 0xf4499b44 in psi_ffi_handler (sig=0x92e0fa0, result=0xffff9760,
args=0xffff96f0, data=0x9341658)
at /home/dmitry/php/ext-psi/src/libffi.c:387
#3 0xf4467a76 in ffi_closure_SYSV_inner () from /lib/libffi.so.6
#4 0xf4467eb6 in ffi_closure_SYSV () from /lib/libffi.so.6
#5 0x08701d21 in ZEND_DO_FCALL_BY_NAME_SPEC_RETVAL_USED_HANDLER () at
/home/dmitry/php/php-master/Zend/zend_vm_execute.h:890
#6 0x0875fd12 in execute_ex (ex=0xf421d020) at
/home/dmitry/php/php-master/Zend/zend_vm_execute.h:54819
#7 0x087643b1 in zend_execute (op_array=0xf426c460, return_value=0x0) at
/home/dmitry/php/php-master/Zend/zend_vm_execute.h:59987
#8 0x086b0d2f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/dmitry/php/php-master/Zend/zend.c:1566
#9 0x0863cdde in php_execute_script (primary_file=0xffffcbbc) at
/home/dmitry/php/php-master/main/main.c:2467
#10 0x0876676a in do_cli (argc=2, argv=0x90e4850) at
/home/dmitry/php/php-master/sapi/cli/php_cli.c:1011
#11 0x087673b2 in main (argc=2, argv=0x90e4850) at
/home/dmitry/php/php-master/sapi/cli/php_cli.c:1404
execute_data is NULL
Did you test ext-psi with php-master?
As I understood, you create libffi callback/closure for each function declared
in *.psi file(s).
And then use it to call a general psi_ffi_handler().
Why not to call a general function handler in first place (without any ffi
magic)?
Thanks. Dmitry.
________________________________
From: Dmitry Stogov
Sent: Thursday, April 26, 2018 12:25:37 PM
To: Michael Wallner
Cc: Dmitry Stogov; Stanislav Malyshev; Zeev Suraski; Xinchen Hui; Nikita Popov;
Bob Weinand; Anatol Belski (a...@php.net); PHP internals list
Subject: Re: [PHP-DEV] PHP FFI extenesion
hi Michael,
On Apr 26, 2018 10:31 AM, Michael Wallner <m...@php.net> wrote:
Hey Dmitry!
On 17/04/18 09:29, Dmitry Stogov wrote:
> hi Michael,
>
> it's pitty, I didn't found this extension before.
> thanks for pointing, I'll definetly take a look.
Did you have a chance to look at it yet?
Yeah. I took a look through API and implementation, but didn't try to use it in
action.
I exited by the amount of work you did, and see advantages in your approach,
but in general, I like to provide a bit different thing.
Acttually, my FFI extension inspired by LuaJit implementation (copied by Python
cffi ABI mode).
I prefer exteremely simple API, simple and compact implementation. I
especially, selected run-time binding, because plan to integrate FFI with JIT
(main advantage of LuaJit).
[see below]
> I, also, like the idea of preloading ffi definitions on startup, but I
> would prefer to allow preloading any php files. Especially for FFI, PHP
> wrappers would able to hide dangerous implementation details.
>
I'm not sure the one depends on the other, and how would that be
different to opcache?
With PSI everything related C is encapsulated, you cannot change
anything regarding the access or calling scheme at runtime.
I admit, PSI is far away from being optimized or even finished yet, but
there are a few important key differentiation points:
- the system administrator controls FFI
- parses C headers, no need to duplicate declarations
- function call and data access is pre-defined, not at runtime
Yeah. I see these differences. Reuse of system headers is definitely a big
advantage.
Pre-loading and absence of run-time definition, is good from security poin of
view, but makes usage a bit more complex. The thing, I don't like, is a special
binding language.
Most probably, both FFI and PSI might be better, taking ideas from the other...
Did you use PSI with some complex libraries?
Thanks. Dmitry.
--
Regards,
Mike
Hey Dmitry!
On 17/04/18 09:29, Dmitry Stogov wrote:
> hi Michael,
>
> it's pitty, I didn't found this extension before.
> thanks for pointing, I'll definetly take a look.
Did you have a chance to look at it yet?
> I, also, like the idea of preloading ffi definitions on startup, but I
> would prefer to allow preloading any php files. Especially for FFI, PHP
> wrappers would able to hide dangerous implementation details.
>
I'm not sure the one depends on the other, and how would that be
different to opcache?
With PSI everything related C is encapsulated, you cannot change
anything regarding the access or calling scheme at runtime.
I admit, PSI is far away from being optimized or even finished yet, but
there are a few important key differentiation points:
- the system administrator controls FFI
- parses C headers, no need to duplicate declarations
- function call and data access is pre-defined, not at runtime
--
Regards,
Mike
