PHP FFI extenesion

> On 26 04 2018, at 20:47, Dmitry Stogov <dmitry@zend.com> wrote: > > 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)? >

> Now, I got your idea. > > Subclassing CData, and use that types for type hinting may make sense. > > I'll put this idea in my TODO, but with low priority. > > > Thanks. Dmitry. > ------------------------------ > *From:* Michał Brzuchalski <michal@brzuchalski.com> > *Sent:* Tuesday, April 17, 2018 10:51:32 AM > > *To:* Dmitry Stogov > *Cc:* Stanislav Malyshev; Zeev Suraski; Xinchen Hui; Nikita Popov; Bob > Weinand; Anatol Belski (ab@php.net); PHP internals list > *Subject:* Re: [PHP-DEV] PHP FFI extenesion > > > > 2018-04-17 9:46 GMT+02:00 Dmitry Stogov <dmitry@zend.com>: > > Hi Michal, > > > I didn't think in this way. I liked to make the simplest API. > > I don't expect wide FFI usage in frameworks :) > > > BTW: I like the idea of use C type names (probably, we may reuse original > C type names without additional registration). > > > currently we can do: $tz = $libc->new("struct timezone"); > > > My point was ability to provide an identity to objects wich acts as a > structs. CData class has no idea of what struct type it is and I cannot > type hint over that, thats why I thought it would be usefull. > I could then prepare a vendor using pure PHP and wrap everything using > types. > > > > I'll think, if we can existend API to use something like: $tz = > FFI::new($libc->timezone); > > At least, this should eliminate C parsing overhead. > > > Thanks. Dmitry. > ------------------------------ > *From:* Michał Brzuchalski <michal@brzuchalski.com> > *Sent:* Tuesday, April 17, 2018 10:24:02 AM > *To:* Dmitry Stogov > *Cc:* Stanislav Malyshev; Zeev Suraski; Xinchen Hui; Nikita Popov; Bob > Weinand; Anatol Belski (ab@php.net); PHP internals list > *Subject:* Re: [PHP-DEV] PHP FFI extenesion > > Hi Dmitry! > > I am not much experienced with C but as a user, I'm just wondering if > there is a possibility to extend FFI class and autoregister all or just > chosen structs as classes, for eg. > class Libc extends FFI { > public function __construct() { > parent::__construct("...code", "...lib"); // tmp notation > $this->register('struct timeval', Libc\Timeval::class); // I > assume they would extend CData > $this->register('struct timezone', Libc\Timezone::class); // as > above > } > } > > So I can instantiate > > $tz = new Libc\Timezone(); > $tv = new Libc\Timeval(); > > and then pass them FFI function > > (new Libc())->gettimeofday($tv, $tz); > var_dump($tv-tv_sec, $tv->tv_usec, $tz); > > I would be able to prepare than a vendor package with a specified > autoloader. > Would that make sense? > > Also wouldn't it better if CData class share the same prefixes like > FFICdata or FFI\CData? > > > Cheers, > Michal > > 2018-04-17 9:18 GMT+02:00 Dmitry Stogov <dmitry@zend.com>: > > > > On Apr 17, 2018 2:49 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote: > Hi! > > > I've spent some time thinking about simple FFI for PHP, and finally, > borrowed most ideas from LuaJIT. > > > > This is an initial PoC. It was tested on Linux only. > > > > > > https://github.com/dstogov/php-ffi > > > > > > I would appreciate review, comments and ideas about missing features and > functionality. > > > > Looks interesting. On a cursory look, couple of thoughts: > - I think all the classes involved should be made non-serializable and > non-unserializable. > > Agree. > > - Does it load shared libraries, or only uses ones already loaded? If > the former, I think there should be a way to unload them at the request > end (even though it might be performance issue, and may be not possible > if persistent resources are involved), otherwise we leak state between > requests. > > I have a bit opposit idea. We will keep FFI for CLI but disable it for web > apps (like dl()). > At the same time, we will develop a technology to preload and reuse PHP > files across requests. > And allow FFI there. > > - OTOH, people may want to load a set of persistent definitions from a > config file, etc. - the ffi definition probably won't change much, and > having locked down set of FFI interfaces the rest of the code is using > might be beneficial > > Yeah. Like this. > > - Since this thing is dealing with raw pointers, etc., from PHP code, > there may be a lot of crashes from using this extension in a wrong way. > I wonder which facilities we could provide for helping people to debug > it (for people who aren't super-comfortable using gdb on PHP engine). > > Programming using FFI, is very similar to C. > I'm not sure, if we may provide good debugging facilities. > > Thanks for review. > > Dmitry. > > > -- > Stas Malyshev > smalyshev@gmail.com > > Hi! > > > I've spent some time thinking about simple FFI for PHP, and finally, > borrowed most ideas from LuaJIT. > > > > This is an initial PoC. It was tested on Linux only. > > > > > > https://github.com/dstogov/php-ffi > > > > > > I would appreciate review, comments and ideas about missing features and > functionality. > > > > Looks interesting. On a cursory look, couple of thoughts: > - I think all the classes involved should be made non-serializable and > non-unserializable. > - Does it load shared libraries, or only uses ones already loaded? If > the former, I think there should be a way to unload them at the request > end (even though it might be performance issue, and may be not possible > if persistent resources are involved), otherwise we leak state between > requests. > - OTOH, people may want to load a set of persistent definitions from a > config file, etc. - the ffi definition probably won't change much, and > having locked down set of FFI interfaces the rest of the code is using > might be beneficial > - Since this thing is dealing with raw pointers, etc., from PHP code, > there may be a lot of crashes from using this extension in a wrong way. > I wonder which facilities we could provide for helping people to debug > it (for people who aren't super-comfortable using gdb on PHP engine). > > -- > Stas Malyshev > smalyshev@gmail.com > > > > > -- > regards / pozdrawiam, > -- > Michał Brzuchalski > about.me/brzuchal > brzuchalski.com > > > > > -- > regards / pozdrawiam, > -- > Michał Brzuchalski > about.me/brzuchal > brzuchalski.com >