# [RFC] Module API Introspection - Thread: https://externals.io/message/71494 - Original archive: https://news-web.php.net/php.internals/71494 - Started by Sara Golemon on 2014-01-24T10:31:13+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #71494 — Sara Golemon — 2014-01-24T10:31:13+00:00 URL: https://externals.io/message/71494#71494 http://wiki.php.net/rfc/moduleapi-inspection --- ## #71495 — Pierre Joye — 2014-01-24T10:55:09+00:00 URL: https://externals.io/message/71494#71495 · In reply to: #71494 hi, > http://wiki.php.net/rfc/moduleapi-inspection Very handy. I do not think we need much discussions about it :) -- Pierre @pierrejoye | http://www.libgd.org --- ## #71498 — Julien Pauli — 2014-01-24T12:41:44+00:00 URL: https://externals.io/message/71494#71498 · In reply to: #71495 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 --- ## #71503 — johannes@schlueters.de — 2014-01-24T13:02:21+00:00 URL: https://externals.io/message/71494#71503 · In reply to: #71494 > http://wiki.php.net/rfc/moduleapi-inspection > 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 --- ## #71504 — Julien Pauli — 2014-01-24T14:01:31+00:00 URL: https://externals.io/message/71494#71504 · In reply to: #71503 On Fri, Jan 24, 2014 at 2:02 PM, Johannes Schlüter 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 --- ## #71505 — johannes@schlueters.de — 2014-01-24T14:15:27+00:00 URL: https://externals.io/message/71494#71505 · In reply to: #71504 > > […] > symols > > […] > doesn't > > […] > > 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. > 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. > > […] > found > > […] > > 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. > 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 --- ## #71506 — Julien Pauli — 2014-01-24T14:29:53+00:00 URL: https://externals.io/message/71494#71506 · In reply to: #71505 On Fri, Jan 24, 2014 at 3:15 PM, Johannes Schlüter wrote: > > > […] > 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. > > > […] > 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 --- ## #71507 — johannes@schlueters.de — 2014-01-24T15:07:53+00:00 URL: https://externals.io/message/71494#71507 · In reply to: #71506 Hi, > > […] > > 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; }\ + ZEND_DLEXPORT int this_extension_was_compiled_for_ ## PHP_VERSION() {return 1;} \ END_EXTERN_C() 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 --- ## #71537 — Stas Malyshev — 2014-01-24T22:54:15+00:00 URL: https://externals.io/message/71494#71537 · In reply to: #71494 Hi! > http://wiki.php.net/rfc/moduleapi-inspection Nice idea, I like it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #71538 — Will Fitch — 2014-01-25T00:36:47+00:00 URL: https://externals.io/message/71494#71538 · In reply to: #71494 > http://wiki.php.net/rfc/moduleapi-inspection Why is this just now becoming a part of PHP? Nice job, Sara. --- ## #71551 — Julien Pauli — 2014-01-25T09:26:41+00:00 URL: https://externals.io/message/71494#71551 · In reply to: #71538 > > > > > […] > > 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