Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102079
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 104.47.36.100 cause and error)
To: Michael Wallner <mike@php.net>
CC: Stanislav Malyshev <smalyshev@gmail.com>, Zeev Suraski <zeev@zend.com>,
	Xinchen Hui <laruence@gmail.com>, Nikita Popov <nikic@php.net>, Bob Weinand
	<bwoebi@php.net>, "Anatol Belski (ab@php.net)" <ab@php.net>, "PHP internals
 list" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] PHP FFI extenesion
Thread-Index: AQHT0yrBnLpXxgz1HEWdw/jxKSLJkaQEFM4AgABk3QCAABugkIAOJYwAgAAf5oOAAJf2BQ==
Date: Thu, 26 Apr 2018 18:47:45 +0000
Message-ID: <BN6PR02MB3234AD5393026DAFE1960EF2BF8E0@BN6PR02MB3234.namprd02.prod.outlook.com>
References: <BN6PR02MB323404E036380FA42924D9A7BFB30@BN6PR02MB3234.namprd02.prod.outlook.com>
 <56794c33-a728-d399-2462-b62ba1b7a509@gmail.com>
 <bd88b528-f9ad-dedf-fe07-d38bc3b8fca8@php.net>
 <a03dfaa3-899f-4dae-8752-ba6a117277bf@email.android.com>,<739e66c6-e60b-005e-acb0-d5c4fb2da11d@php.net>,<6760eb1f-4345-48d2-a5c2-727cd98e3ac2@email.android.com>
In-Reply-To: <6760eb1f-4345-48d2-a5c2-727cd98e3ac2@email.android.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BN6PR02MB3234AD5393026DAFE1960EF2BF8E0BN6PR02MB3234namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fe9ba46a-4ca0-4cb1-cee4-08d5aba63320
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2018 18:47:45.1470
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR02MB2354
Subject: Re: [PHP-DEV] PHP FFI extenesion
From: dmitry@zend.com (Dmitry Stogov)

--_000_BN6PR02MB3234AD5393026DAFE1960EF2BF8E0BN6PR02MB3234namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Michael,


I've just tried to run PSI with php-master (32-bit DEBUG build) and got SIG=
SEGV 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=3D0xf426c500, execute_da=
ta=3D0x0) at /home/dmitry/php/ext-psi/src/call.c:273
#1  0xf4494fe7 in psi_context_call (C=3D0x92dfe90, execute_data=3D0x0, retu=
rn_value=3D0x8fc0144 <HARDCODED_INI+4>, impl=3D0x9341658)
    at /home/dmitry/php/ext-psi/src/context.c:250
#2  0xf4499b44 in psi_ffi_handler (sig=3D0x92e0fa0, result=3D0xffff9760, ar=
gs=3D0xffff96f0, data=3D0x9341658)
    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 /hom=
e/dmitry/php/php-master/Zend/zend_vm_execute.h:890
#6  0x0875fd12 in execute_ex (ex=3D0xf421d020) at /home/dmitry/php/php-mast=
er/Zend/zend_vm_execute.h:54819
#7  0x087643b1 in zend_execute (op_array=3D0xf426c460, return_value=3D0x0) =
at /home/dmitry/php/php-master/Zend/zend_vm_execute.h:59987
#8  0x086b0d2f in zend_execute_scripts (type=3D8, retval=3D0x0, file_count=
=3D3) at /home/dmitry/php/php-master/Zend/zend.c:1566
#9  0x0863cdde in php_execute_script (primary_file=3D0xffffcbbc) at /home/d=
mitry/php/php-master/main/main.c:2467
#10 0x0876676a in do_cli (argc=3D2, argv=3D0x90e4850) at /home/dmitry/php/p=
hp-master/sapi/cli/php_cli.c:1011
#11 0x087673b2 in main (argc=3D2, argv=3D0x90e4850) 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 decla=
red 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 Po=
pov; Bob Weinand; Anatol Belski (ab@php.net); PHP internals list
Subject: Re: [PHP-DEV] PHP FFI extenesion

hi Michael,


On Apr 26, 2018 10:31 AM, Michael Wallner <mike@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 i=
t 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 Py=
thon cffi ABI mode).
I prefer exteremely simple API, simple and compact implementation. I especi=
ally, selected run-time binding, because plan to integrate FFI with JIT (ma=
in 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 othe=
r...

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


--_000_BN6PR02MB3234AD5393026DAFE1960EF2BF8E0BN6PR02MB3234namp_--