hi,
Very handy. I do not think we need much discussions about it :)
--
Pierre
@pierrejoye | http://www.libgd.org
We talked about this with Sara this morning, but I see she already
worked on a patch :D
Wonderful.
Can we use this step to merge this as well ?
https://github.com/jpauli/php-src/tree/remove_old_php4_dl
I can update the RFC if needed.
Perhaps we could as well refactor the code as Sara's patch uses nearly
the same code as in dl.c ?
Thoughts ?
Julien.P
hi,
Very handy. I do not think we need much discussions about it :)
--
Pierre@pierrejoye | http://www.libgd.org
the idea is neat, i however wonder how often this will not work due to
missing symbols. At least on systems which support that we dlopen()
using the DL_LOAD flag to lazy load which will often prevent that
error.
Cases where this can fail, form top of my head, are at least
* extensions trying to hack get_module() (if you are crazy you can
create your own get_module() which detects the PHP version and
does compatibility magic, one binary for all, yes that exists
and works)
* accessing PHP symbols from the init section (i.e. from default
constructors being called for global variables in C++
extensions)
* I think (didn't check) there will be issues due to tsrm symols
when an extension provides INI options and TSRM/non-TSRM doesn't
match
* Afaik Windows' LoadLibrary doesn't do lazy loading but will
confront the user with a dialog box when symbols can't be found
* ... I'm sure there are more
johannes
On Fri, Jan 24, 2014 at 2:02 PM, Johannes Schlüter
johannes@schlueters.de wrote:
the idea is neat, i however wonder how often this will not work due to
missing symbols. At least on systems which support that we dlopen()
using the DL_LOAD flag to lazy load which will often prevent that
error.
Nice catch. However, sure, there will be failing cases like there are
when loading extensions.
We just can't get rid off them, and have to leave with them, like our
extension system works today.
Sara's patch anyway use the same macros used in the extension system
(DL_LOAD, particulary, which uses RTLD_LAZY).
Cases where this can fail, form top of my head, are at least
* extensions trying to hack get_module() (if you are crazy you can create your own get_module() which detects the PHP version and does compatibility magic, one binary for all, yes that exists and works)
Quiet uncommon isn't it ?
The same can be said with actual extension system, this can even lead
to security holes, but we just cant do anything about this.
* accessing PHP symbols from the init section (i.e. from default constructors being called for global variables in C++ extensions)
Same : that is an edge case, pretty uncommon as well, 99.9% of
extension developpers dont do that.
* I think (didn't check) there will be issues due to tsrm symols when an extension provides INI options and TSRM/non-TSRM doesn't match
I don't get it. We access very few fields of zend_module_entry, and
they are all placed before the _zend_ini_entry one. So if there is a
problem of alignment mismatch, we won't be affected AFAIK.
* Afaik Windows' LoadLibrary doesn't do lazy loading but will confront the user with a dialog box when symbols can't be found * ... I'm sure there are more
Same : the same happens on WIndows when you try to load an extension.
So , we already manage this behavior and cant do anything about it.
Julien
* I think (didn't check) there will be issues due to tsrmsymols
when an extension provides INI options and TSRM/non-TSRMdoesn't
matchI don't get it. We access very few fields of zend_module_entry, and
they are all placed before the _zend_ini_entry one. So if there is a
problem of alignment mismatch, we won't be affected AFAIK.
INI settings are in a global variable, referring to specific update
handlers. I remember cases where the error while loading extensions was
about missing OnUpdateBool. I can imagine other similar errors.
* Afaik Windows' LoadLibrary doesn't do lazy loading but will confront the user with a dialog box when symbols can't befound
* ... I'm sure there are moreSame : the same happens on WIndows when you try to load an extension.
So , we already manage this behavior and cant do anything about it.
The point is: What is the benefit of such a feature if it often can't be
used? Maybe we can think more and find a better way to approach this?
I don't have a better idea than something like a shell script doing
strings xdebug.so | grep API -- which obviously is no good idea
either, but maybe somebody is smarter than me.
On Windows one can right click -> properties in explorer which gives
info. That's nice.
johannes
On Fri, Jan 24, 2014 at 3:15 PM, Johannes Schlüter
johannes@schlueters.de wrote:
* I think (didn't check) there will be issues due to tsrmsymols
when an extension provides INI options and TSRM/non-TSRMdoesn't
matchI don't get it. We access very few fields of zend_module_entry, and
they are all placed before the _zend_ini_entry one. So if there is a
problem of alignment mismatch, we won't be affected AFAIK.INI settings are in a global variable, referring to specific update
handlers. I remember cases where the error while loading extensions was
about missing OnUpdateBool. I can imagine other similar errors.* Afaik Windows' LoadLibrary doesn't do lazy loading but will confront the user with a dialog box when symbols can't befound
* ... I'm sure there are moreSame : the same happens on WIndows when you try to load an extension.
So , we already manage this behavior and cant do anything about it.The point is: What is the benefit of such a feature if it often can't be
used? Maybe we can think more and find a better way to approach this?
I'm all open to new ideas :-)
I don't have a better idea than something like a shell script doing
strings xdebug.so | grep API-- which obviously is no good idea
either, but maybe somebody is smarter than me.
That's what we ended telling to attendees : we have no way in PHP
actually to check the API of an extension, except by trying to load
it.
However, GNU tools playing with ELF format are a global Unix solution
working, but not coming from PHP obviously.
The only safe thing we could do, is wrapping libelf and play with it.
Somehow dirty and adds a new dependency :-p
Julien
Hi,
I don't have a better idea than something like a shell script doing
strings xdebug.so | grep API-- which obviously is no good idea
either, but maybe somebody is smarter than me.That's what we ended telling to attendees : we have no way in PHP
actually to check the API of an extension, except by trying to load
it.
Trying to load it will actually tell the user exactly the same as this
new option, it will either
* load it successfully,
* report PHP's and the extensions API numbers or
* result in a symbol lookup error
Contrary to the patch loading it will mind php.ini's extension dir.
Right now
php --modinfo=foo.so
and
php -m -dextension=foo.so
will load different files (--modinfo's behavior can be seen as correct,
but this difference is confusing)
However, GNU tools playing with ELF format are a global Unix solution
working, but not coming from PHP obviously.The only safe thing we could do, is wrapping libelf and play with it.
Somehow dirty and adds a new dependency :-p
Another crazy idea I just had was along those lines:
#define ZEND_GET_MODULE(name)
BEGIN_EXTERN_C()
ZEND_DLEXPORT zend_module_entry *get_module(void) { return &name##_module_entry; }\
-
END_EXTERN_C()ZEND_DLEXPORT int this_extension_was_compiled_for_ ## PHP_VERSION() {return 1;} \
and then a shell script greping "this_extension_was_compiled_for" in the
ldd output. This exact patch obviously won't work (PHP define in zend
header, points in C function name, ...) but maybe somebody has more
creativity for that.
johannes
Hi!
Nice idea, I like it.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Why is this just now becoming a part of PHP? Nice job, Sara.
Why is this just now becoming a part of PHP? Nice job, Sara.
Well, as Johannes stated, there still exists problems.
What we do so ? Should we merge a "best solution so far" , or just
give up with the idea ?
Julien