compiled mod_php apache2 module needs to do ELF segment relocations: scanelf -a /usr/lib/apache2/extramodules/libphp4.so TYPE TEXTREL FILE ET_DYN TEXTREL /usr/lib/apache2/extramodules/libphp4.so When CONFIG_PAX_NOELFRELOCS is enabled in the kernel (hardened-sources-2.6.11-r1) apache2 won't start: gw root # /etc/init.d/apache2 restart * Apache2 has detected a syntax error in your configuration files: Syntax error on line 6 of /usr/lib/apache2/conf/modules.d/70_mod_php.conf: Cannot load /usr/lib/apache2/extramodules/libphp4.so into server: /usr/lib/apache2/extramodules/libphp4.so: cannot make segment writable for relocation: Permission denied gw root # This is as expected and can be fixed by disabling PaX restrictions on the apache2 daemon, but that's not a good thing (TM). webservers of all daemons should really be restricted. I don't know if mod_php can be compiled without TEXTREL, but it would help a lot in hardened setups. Reproducible: Always Steps to Reproduce: 1. use hardened-sources-2.6.11-r1 or vanilla kernel with grsecurity or pax patchset 2. compile kernel with CONFIG_PAX=y # CONFIG_PAX_SOFTMODE is not set CONFIG_PAX_PT_PAX_FLAGS=y # CONFIG_PAX_NO_ACL_FLAGS is not set CONFIG_PAX_HAVE_ACL_FLAGS=y CONFIG_PAX_NOEXEC=y # CONFIG_PAX_PAGEEXEC is not set CONFIG_PAX_SEGMEXEC=y (using PAGEEXEC or SEGMEXEC is fine as long as one of them is used) # CONFIG_PAX_EMUTRAMP is not set CONFIG_PAX_MPROTECT=y CONFIG_PAX_NOELFRELOCS=y (above config flag is critical to reproduce bug) CONFIG_PAX_ASLR=y CONFIG_PAX_RANDKSTACK=y CONFIG_PAX_RANDUSTACK=y CONFIG_PAX_RANDMMAP=y CONFIG_PAX_NOVSYSCALL=y 3. build hardened toolchain USE="hardened pic" emerge gcc glibc USE="hardened pic" emerge gcc glibc 4. compile mod_php and apache2 USE="hardened pic -java" emerge apache2 mod_php 5. try to start apache2 with -DPHP4 enabled in /etc/conf.d/apache2 6. apache2 won't start Actual Results: gw root # /etc/init.d/apache2 restart * Apache2 has detected a syntax error in your configuration files: Syntax error on line 6 of /usr/lib/apache2/conf/modules.d/70_mod_php.conf: Cannot load /usr/lib/apache2/extramodules/libphp4.so into server: /usr/lib/apache2/extramodules/libphp4.so: cannot make segment writable for relocation: Permission denied gw root # Expected Results: gw root # /etc/init.d/apache2 start * Starting apache2... [ ok ] gw root # Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.200 41102-r1, 2.6.11.7-grsec i686) ================================================================= System uname: 2.6.11.7-grsec i686 Pentium III (Coppermine) Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, May 6 2005, 17:45:06)] ccache version 2.3 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -fomit-frame-pointer -fforce-addr -fstack-protector -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/ config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -fomit-frame-pointer -fforce-addr -fstack-protector -O 2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.rnl.ist.utl.pt/gentoo http://gentoo.oregonstate.edu ht tp://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://ftp.rnl.ist.utl.pt/gentoo-portage" USE="x86 aalib acl acpi alsa apache2 apm arts avi berkdb bitmap-fonts crypt csco pe cups curl emboss encode fam foomaticdb fortran gd gdbm ggi gif gmp gpm gtk2 h ardened imagemagick imap imlib ipv6 java jpeg libg++ libwww mad maildir mikmod m mx motif mp3 mpeg mppe-mppc mysql ncurses nls ogg oggvorbis opengl oss pam pdfli b perl pic pie png ppds python quicktime readline samba sasl sdl slang snmp spel l sse ssl svga tcpd tiff truetype-fonts type1-fonts unicode usb vorbis winbind w mf xml xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLA Y
Reassigning to hardened
Unassigning from hardened.. This is a Q/A problem. shared libs must not contain text relocations. Portage will refuse to install shared libs like this in the future. The rumored proper fix is reported to be to "not" --enable-assembler in MySQL that gets later used by the libphp4.so
well, disabling the assembly code is more like a workaround, not a real fix ;-). it obviously points to some assembly that is not PIC, i'll look at it but make no promises for fixing it, ideally upstream should handle it (do they know about this at all?).
I'm not going to use --disable-assembler, as that is a workaround with a large performance impact in this case. See bug 42968 and tell me HOW to fix the PIC asm, and I'll gladly take a stab at it. Upstream was informed previously, but considered it very low priority (eg submit a patch and we'll take it).
USE=pic and disable would be an acceptable compromise till such time as a proper asm fix exists.
"USE=pic and disable would be an acceptable compromise till such time as a proper asm fix exists." could you repeat please? either I didn't understand or the sentence has some typos...
Pedro comment #5 was in response to comment #4 IE: I'm letting robbat2 know that despite the performance gains from using --enable-assembler it's acceptable to use --disable-assembler in the case when pic is found in the users USE flags. This will allow mysql to built properly for those that need it to be and will probably solves the php bugs that people have with not being able to enable memory protection after relocatable section blah.. The pic flag in portage is more or less meant for this very thing. Lets watch and see how 42968 progresses first. Kevin might come up with a patch that will make things even faster while fixing a general ELF q/a problem.
*** This bug has been marked as a duplicate of 42968 ***
after changing --enable-assembler into --disable-assembler and recompiling mod_php, the result is the same. libphp4.so still has TEXTREL. apparently it isn't so because of mysql... since it isn't solved, maybe the bug should be marked as open again?
(In reply to comment #9) > after changing --enable-assembler into --disable-assembler and recompiling > mod_php, the result is the same. libphp4.so still has TEXTREL. apparently it > isn't so because of mysql... can you post (attach) the 'readelf -a /path/to/libphp4.so' output please (if it's too big, then just -edr instead of -a)? > since it isn't solved, maybe the bug should be marked as open again? if libphp4.so has textrels (we'll see that from the above output) then it's indeed a different bug.
Created attachment 59119 [details] output of readelf -a /usr/lib/apache2/extramodules/libphp4.so gzipped text with output of readelf -a /usr/lib/apache2/extramodules/libphp4.so
scanelf shows that libphp4.so indeed has text relocations even when recompiled with "fixed" mysql. gw root # scanelf -a /usr/lib/apache2/extramodules/libphp4.so TYPE PAX STK/REL TEXTREL RPATH NEEDED INTERP FILE ET_DYN PeMRxS RW- R-- TEXTREL - libcrypt.so.1,libnsl.so.1,libsablot.so.0,libexpat.so.0,libaspell.so.15,libpspell.so.15,libpdf.so.2,libz.so.1,libtiff.so.3,libpng.so.3,libmysqlclient.so.12,libmhash.so.2,libmcrypt.so.4,libltdl.so.3,libssl.so.0.9.7,libcrypto.so.0.9.7,libpam.so.0,libgmp.so.3,libjpeg.so.62,libexslt.so.0,libxslt.so.1,libdb-4.1.so,libdb.so.2,libgdbm.so.3,libbz2.so.1,libresolv.so.2,libm.so.6,libxmlparse.so.0,libxmltok.so.0,libcurl.so.3,libdl.so.2,libxml2.so.2,libnetsnmp.so.5,libwrap.so.0,libc.so.6 - /usr/lib/apache2/extramodules/libphp4.so gw root #
I just added elfutils-0.108 to the tree (~arch) which includes a program named eu-findtextrel I'm not sure if <=elfutils-0.101 contains this util or not, but it appears as if it will come in quite handy in helping tack down the source of TEXTREL's in the future. Could you please give it a try. eu-findtextrel /usr/lib/apache2/extramodules/libphp4.so > php-textrel.x
(In reply to comment #12) > scanelf shows that libphp4.so indeed has text relocations even when recompiled > with "fixed" mysql. indeed, it has a lot of them, i think it's due to some other library or at least a subtree in php not having been compiled as PIC, i'll take a look. in the meantime you can reopen this bug ;-)
(In reply to comment #13) > I just added elfutils-0.108 to the tree (~arch) which includes a program named > eu-findtextrel > I'm not sure if <=elfutils-0.101 contains this util or not, but it appears as if > it will come in quite handy in helping tack down the source of TEXTREL's in the > future. > > Could you please give it a try. > eu-findtextrel /usr/lib/apache2/extramodules/libphp4.so > php-textrel.x attaching output of eu-findtextrel and reopening bug.
Created attachment 59199 [details] output of eu-findtextrel /usr/lib/apache2/extramodules/libphp4.so output of eu-findtextrel /usr/lib/apache2/extramodules/libphp4.so, trying to find sources of textrelocations.
passing this onto PHP guys, since it is not due to MySQL
I'm having the same problems with php5. I get the same error. Cannot load /usr/lib/apache/libphp5.so into server: /usr/lib/apache/libphp5.so: cannot make segment writable for relocation: Permission denied I've traced the error back to the switch --with-mysql=/xxx/xxx/ when compiling php from source. In case of emerge that probably would be mysql. I've still haven't found a solution for this problem. Any help would be great
took a look at it finally, and the fix is simple: add myconf="${myconf} --with-pic" to the ebuild (src_compile) and configure will prefer building and using PIC instead of the apparent default of non-PIC.
Ok thanks for looking into this, though we already do that... All the PHP eclasses (both for new and old style PHP) do: # fix ELF-related problems if has_pic ; then myconf="${myconf} --with-pic" fi So we already added that, now I've not tried lately to run mod_php with TEXTRELs disabled, but in theory the fix was already there. :) It would be great if you could test this with one of the new dev-lang/php PHP ebuilds, thanks. Best regards, CHTEKK.
something's amiss here. let's see dev-php/mod_php-4.4.0-r3 which i was playing with (note that the original report was for mod_php as well, not for php itself). regardless of pic in USE, configure doesn't get passed --with-pic here (and while we're at it, the pic USE flag should not play a role, a shared lib must be PIC, without textrels) and the resulting .so has textrels all over the place. now i don't know if the mod_php ebuild was supposed to pick up whatever changes you had in the eclasses or not, but it definitely doesn't work as it is, hence my suggested quick fix. based on what you said i suggest you 1. get rid of the USE=pic dependence 2. use that eclass/whatever in the mod_php ebuilds as well.
There is no "pic" USE flag for any PHP ebuild, has_pic is a function from the flag-o-matic eclass that just checks that the system on wich we're building does indeed support PIC code. Also, mod_php is being deprecated in favour of dev-lang/php, wich builds all three SAPIs depending on USE flags "apache2" "cli" "cgi", there you can also see very well if --with-pic gets added, "Enabling PIC support" should appear after it enables/disables the extensions, and indeed the finished mod_php has --with-pic in it, I just have no Hardened system with TEXTRELs disabled on wich to test it. For more informations on dev-lang/php see [1]. Best regards, CHTEKK. [1] http://svn.gnqs.org/projects/gentoo-php-overlay/file/docs/php-upgrading.html?format=raw
hmm, things are still not clear to me... 1. has_pic doesn't check for PIC support (what would that mean anyway?), it checks for the presence of -fPIC/-fpic in CFLAGS, therefore it's effectively the same as what the pic USE flag does (or did in the past), iirc. in other words, unless -fPIC is in someone's CFLAGS (very bad idea), has_pic won't do much good for you (emerge mod_php yourself if you don't believe it). note also that has_pic is marked as DEPRECATED in flag-o-matic.eclass. quite honestly i don't understand why you need this has_pic or any PIC related check at all, any package that builds shared libs must build them without text relocations (which means that it must be compiled with -fPIC or -fpic, and if it has assembly code then that has to be properly written too, see our previous work on mysql and others) and i think most if not all of them already provide proper configure switches for that effect. 2. even if dev-php/mod_php is deprecated, it should be fixed as there are apparently people using it (see comment #18), and use_pic doesn't do what you think it does. 3. i don't know how dev-lang/php is supposed to build with -fPIC, but if, as you say, it relies on has_pic then it's failing as well (just tried it on dev-lang/php-5.0.5-r1): checking whether to force non-PIC code in shared modules... yes and of course i see -prefer-non-pic all over the place during compilation and then the QA checks trigger at the end too: TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/curl.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/dba.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/ftp.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/gettext.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/gmp.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/iconv.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/mbstring.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/mcrypt.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/ncurses.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/openssl.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/pcntl.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/sockets.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/sysvmsg.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/sysvsem.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/sysvshm.so TEXTREL usr/lib/php5/lib/php/extensions/no-debug-zts-20041030/zlib.so TEXTREL usr/lib/apache2/modules/libphp5.so so the question is, how did you guys manage to compile this thing without text relocations (note that all this happened on a non-hardened gentoo)?
PHP's configure script uses -prefer-non-pic # Disable PIC where it is known to be safe to do so, # to avoid the performance hit from the lost register Benchmarks showed that building PHP with -prefer-non-pic increases performance by 15-20%.
(In reply to comment #24) > PHP's configure script uses -prefer-non-pic > > # Disable PIC where it is known to be safe to do so, > # to avoid the performance hit from the lost register uhm, what do they mean by 'safe to do so'? apparently they don't have the slightest idea about text relocations as they compile *everything* as non-PIC. anyway, can gentoo fix it at least for hardened then? > Benchmarks showed that building PHP with -prefer-non-pic increases performance > by 15-20%. and what would be those benchmarks? i can hardly imagine that the PIC function prologues and variable accesses incur such a performance hit unless there's some other problem hidden there already (e.g., small functions that could/should be inlined aren't, data variables are exported from a shared library (bad idea), too many symbols are visible outside of the shared library without purpose, etc).
(In reply to comment #23) > hmm, things are still not clear to me... > > 1. has_pic doesn't check for PIC support (what would that mean anyway?), it > checks for the presence of -fPIC/-fpic in CFLAGS, therefore it's effectively > the same as what the pic USE flag does (or did in the past), iirc. in other > words, unless -fPIC is in someone's CFLAGS (very bad idea), has_pic won't do > much good for you (emerge mod_php yourself if you don't believe it). note > also that has_pic is marked as DEPRECATED in flag-o-matic.eclass. > > quite honestly i don't understand why you need this has_pic or any PIC > related check at all, any package that builds shared libs must build them > without text relocations (which means that it must be compiled with -fPIC or > -fpic, and if it has assembly code then that has to be properly written too, > see our previous work on mysql and others) and i think most if not all of > them already provide proper configure switches for that effect. Ok yeah you're right on this, it may well be from what I see that all this problem derives from has_pic use, since I just tried to compile PHP 4.4.0 on a Hardened system (where has_pic returned true, and I have no special flags in my CFLAGS), and enabling --with-pic let it compile withouth warnings about TEXTRELs. I'll attach shortly a patch to fix this in the php-sapi.eclass, so it uses the new gcc-specs-pie function from toolchain-funcs eclass, wich should correctly detect things on all Gentoo systems (how I see it, it returns false only if you explicitly disable PIE code, and in that case it should be correct to not build with --with-pic). > 2. even if dev-php/mod_php is deprecated, it should be fixed as there are > apparently people using it (see comment #18), and use_pic doesn't do what > you think it does. If there are problems with it they will be fixed, it's just that we now normally require a confirmation of bugs also in dev-lang/php, and if they're not reproducible, then simply migrate over to dev-lang/php, but I see that the bug probably also appears there (if it indeed is the has_pic that causes problems). Best regards, CHTEKK.
Created attachment 70761 [details, diff] Patch to fix usage of has_pic in php-sapi.eclass This also displays an "Enabling PIC support" during emerge, so you can be sure if it triggered or not. Best regards, CHTEKK.
(In reply to comment #26) > I'll attach shortly a patch to fix this in the php-sapi.eclass, so it > uses the new gcc-specs-pie function from toolchain-funcs eclass, wich should > correctly detect things on all Gentoo systems (how I see it, it returns false > only if you explicitly disable PIE code, and in that case it should be correct > to not build with --with-pic). this is still not good, there're hardened gcc profiles that don't build PIEs by default and hence will trigger your nopie check and still build a shared library with text relocations. that is, PIE determines the executable file format, not that of the shared library, don't tie the two together. according to comment #24 the reason for not enabling PIC shared libs by default was some performance problem, i'd like to know what they are exactly as the bug is there and producing text relocations for a 'fix' is completely wrong. in case anyone has doubts about the badness of textrelocs, read Ulrich Drepper's DSO howto at http://people.redhat.com/drepper/dsohowto.pdf page 13 in particular.
> this is still not good, there're hardened gcc profiles that don't build PIEs by > default and hence will trigger your nopie check and still build a shared library > with text relocations. that is, PIE determines the executable file format, not > that of the shared library, don't tie the two together. Yeah sorry, saw that too when trying out on a non-hardened system for example, bad me for not testing that before attaching the patch. :( Sorry again, at least I can confirm that hard-enabling --with-pic fixes the TEXTRELs. > according to comment #24 > the reason for not enabling PIC shared libs by default was some performance > problem, i'd like to know what they are exactly as the bug is there and > producing text relocations for a 'fix' is completely wrong. in case anyone has > doubts about the badness of textrelocs, read Ulrich Drepper's DSO howto at > > http://people.redhat.com/drepper/dsohowto.pdf > > page 13 in particular. Sebastian, any more precise informations on those performance problems? Anyway I think we should choose "fix the TEXTREL problem" over performance, any another toughts? I'd vote for enabling --with-pic unconditionally then, from what I understand it's the best way to go, solves the problem and anything should support it per http://www.gentoo.org/proj/en/hardened/pic-internals.xml, the only drawback could be a performance decrease. Sorry if some of my ideas may sound strange, but I'm really no expert on the toolchain's inner workings and far to sleepy atm, so till tomorrow, CHTEKK.
There were several discussions about this on the php-internals mailinglist, just search the archives.
(In reply to comment #30) > There were several discussions about this on the php-internals mailinglist, just > search the archives. Found only this commenting on performance loss for PIC enabled PHP: http://marc.theaimsgroup.com/?l=php-dev&m=105976279031095&w=2 But generally the view is that with PIC enabled, PHP will really slow down. Just an idea, we could simply add a "hardened" USE flag to PHP (not "hardenedphp", thats something else), and make --with-pic dependant on that one. Also, we do an ewarn at the beginning and end of the ebuild to warn the user that building without "hardened" enabled will get him a PHP that is faster, but with TEXTRELs. Since has_pic or gcc-specs-pie aren't reliable as checks, a USE hardened should be (the user can directly turn it on/off), normally that one is already set for Hardened-Gentoo systems too, and with the warnings in the ebuild and on our documentation (once it's finished) they'll also know what to do. Any toughts on this? While TEXTRELs are evil, killing off 20% and more performance is too on a loaded webserver... Best regards, CHTEKK.
(In reply to comment #30) > There were several discussions about this on the php-internals mailinglist, just > search the archives. i think i found the relevant ones and all seem to come from one Rasmus Lerdorf who once stated that he gained 10-20% performance by going with a non-PIC build. what he didn't show is the exact benchmarks and performance numbers, let alone profiles so it's kinda hard to assess what he was measuring. has any of you guys reproduced any of these tests? if so, what are the details? if not, can you do it now? also, once you're into benchmarking, i'd like someone to measure the effect of adding -Bsymbolic to LDFLAGS, that should reduce a lot of unnecessary .plt redirections in the .so and could very well make up for the performance loss (my stats on libphp5.so show that it has some 5778 functions that are forced to go through the .plt, probably for no good reason, -Bsymbolic would eliminate the function call overhead on all of that).
Just to pipe in here :) has_pic() - one of my pet hates. People use it all over the place, with everyone thinking it does something different, one of the main reasons I marked it "DEPRECATED" (that, and it's meaningless anyway!). I think it was created to provide a simple way for ebuilds to detect when the hardened compiler has "switched on PIC" - however that completely misses the point as the hardened compiler doesn't "switch on PIC", it switches on PIE for non-PIC objects (so that they can be linked into position-independent executables). Later people started using it to conditionally fix broken asm code in particular, where upstream deliberately build non-PIC objects for their shared libraries - exposed by the hardened compiler which switches on -fPIE which it otherwise wouldn't do (because -fPIC would be present). re. performance issues - I simply don't believe PIC code is so much slower than non-PIC code as such. Certainly claims of 25%-30% are not credible. What is likely happening if someone does see such a large performance difference, is that some apps provide optimised non-PIC assembler code, and fall back to unoptimised C functions when they have to build PIC. The performance drop has nothing to do with PIC being significantly slower than non-PIC per se, but everything to do with the difference between a piece of hand-optimised case-specific assembler and a generic C function. Happens a lot in the media packages. I suspect that the report of a 25-30% hit was due to things like the longlong2str function that didn't have an optimised PIC assembler version in mysql (see bug #42968). Certainly it'd be worth measuring performance of php properly to get some real data.
Ok, I've done some benchmarking using the bench.php benchmark from http://cvs.php.net/co.php/ZendEngine2/bench.php?r=1.4. All the benchmarks were done locally on my machine, here some specs: MinasTirith / # uname -a Linux MinasTirith 2.6.11-gentoo-r9 #2 SMP Tue Jun 7 00:44:14 CEST 2005 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz GenuineIntel GNU/Linux It's a Intel P4 3.2 Ghz, with HT enabled (SMP kernel) and running in 32bit-only mode, it's got 1024MB DDR-RAM and a 60gb ATA133 HD. I have benchmarked PHP 4.4.1RC1, one series of tests consisted in directly executing the bench.php from commandline using the PHP cli binary, and the other series of tests consisted in browsing to bench.php and executing through mod_php under Apache2.0.54 with MPM-Prefork, the cache of the browser (Firefox) I used was always completely cleared between test runs. Each benchmark was repeated three times, and was done for the following PHP configurations: - normal PHP - PHP --with-pic - PHP --with-pic and -Bsymbolic appended to LDFLAGS The results are all available here: http://dl.longitekk.com/cli_phpbench.txt http://dl.longitekk.com/mod_phpbench.txt As you can see, --with-pic indeed slows down PHP, in CLI mode indeed up to 20%, and in mod_php about the same. Further, adding -Bsymbolic, slows down the CLI PHP even more (very little though), but indeed speeds up mod_php, wich still is about three seconds slower than a non-PIC build, and probably adding -Bsymbolic to the non-PIC build would have made that one also faster, thus increasing the difference again (I'm not sure on this though, didn't test that, it just seems logical). Best regards, CHTEKK.
ok, now we're getting somewhere. more questions too ;-) 1. what's this CLI version exactly? in particular, does it link to a shared php.so (which does the real work) or is everything linked into the main executable? i'm asking this because using PIC in the main exe is meaningless for performance evaluation (well, it'd matter for a PIE build, but let's fix things one by one), we care about the shared lib only. 2. for me the more interesting results are for mod_php. as i suspected, part of the overhead is due to the function calls going through the .plt, i'd like to see what -Bsymbolic does to the non-PIC build though. i'd also like to see the detailed numbers like you did for the CLI build (if that's possible), to see which benchmarks take the more significant hits (probably the same as in the CLI version, but double checking it never hurts). next, we'd have to do some profiling to see where the difference is exactly, i'll see if i can set it up here, else i'll have to ask you to do it (it'll need some tweaking in CFLAGS like adding -pg). 3. these tests appear to be more like microbenchmarks, whose results show worst case performance, i wouldn't draw far-reaching conclusions on 'average' real life app performance impact. are there tests that exercise whole apps or at least a bigger code base?
I cannot tell you much about the issue, but I can point you to some links / benchmarks: Rasmus suggestion: -> http://groups.google.de/group/mailing.www.php-dev/browse_frm/thread/97ce816a91f91024/a0c339bcc2b98c60#a0c339bcc2b98c60 Benchmark: -> http://www.schlossnagle.org/~george/blog/index.php?/archives/58-The-DSO-Myth.html -> http://www.schlossnagle.org/~george/blog/index.php?/archives/57-The-DSO-Myth-Part-2.html -- comment from Rasmus (google cache from old blog): -- "George, just because you use a DSO doesn't mean you have to use PIC. You can compile a shared library non-pic. If a shared library is only ever loaded into a single thing, like Apache in this case, the benefits of PIC are minimal anyway, and you still get all the benefits of not needing to recompile your Apache when you upgrade your PHP. So build yourself a non-pic libphp4.so and benchmark again." -> http://www.schlossnagle.org/~george/blog/index.php?/archives/56-The-DSO-Myth-Part-3.html the raw benchmark results: -> http://www.omniti.com/~george/php/stats2 More blogs/benchmarks: -> http://ilia.ws/archives/28-PHPApache-Static-vs-DSO.html -> http://www.derickrethans.nl/pic_vs_nonpic_take_2.php And there are some entries in php.internals weekly summeries (from zend.com): -> http://php.zend.com/zend/week/index.php (search for "pic")
(In reply to comment #35) > ok, now we're getting somewhere. more questions too ;-) Heh well, ok. :) > 1. what's this CLI version exactly? in particular, does it link to a shared > php.so (which does the real work) or is everything linked into the main > executable? i'm asking this because using PIC in the main exe is meaningless > for performance evaluation (well, it'd matter for a PIE build, but let's fix > things one by one), we care about the shared lib only. Yeah, php CLI build is the php binary that can be called from commandline to execute PHP scripts via commandline, it does not load any php.so library, all the PHP stuff is condensed into the binary itself. I tought that probably PIC in a binary wouldn't matter much performancewise, but it's still a good comparison method I think and anyway confirms that PIC seems to be slower. mod_php instead is a shared library that gets loaded into Apache. > 2. for me the more interesting results are for mod_php. as i suspected, part of > the overhead is due to the function calls going through the .plt, i'd like to > see what -Bsymbolic does to the non-PIC build though. I've tested this and added the results at the end of the two txt's containing my benchmark results. > i'd also like to see > the detailed numbers like you did for the CLI build (if that's possible), to > see which benchmarks take the more significant hits (probably the same as in > the CLI version, but double checking it never hurts). This is possible, I just have to recompile and redo all the tests, should be all done in about an hour I think. > next, we'd have to do > some profiling to see where the difference is exactly, i'll see if i can set > it up here, else i'll have to ask you to do it (it'll need some tweaking in > CFLAGS like adding -pg). Ok, this can be done, just guide me through what I need to do exactly, never did profiling, or point me to some doc explaining it in detail. > 3. these tests appear to be more like microbenchmarks, whose results show worst > case performance, i wouldn't draw far-reaching conclusions on 'average' real > life app performance impact. are there tests that exercise whole apps or at > least a bigger code base? Hmmm there probably are, but not that I'm aware of. @ Andreas: thanks for all the links and infos! Best regards, CHTEKK.
Here are the mod_php benchmarks, with all the details: http://dl.longitekk.com/mod_phpbench_detailed.txt Take note that this is all from a recompile&rerun of all benchmarks, and it seems that -Bsymbolic this time didn't change anything much... Why I have no idea, it was passed to the build process... I hope this helps further, best regards, CHTEKK.
(In reply to comment #38) > Here are the mod_php benchmarks, with all the details: > http://dl.longitekk.com/mod_phpbench_detailed.txt > Take note that this is all from a recompile&rerun of all benchmarks, and it > seems that -Bsymbolic this time didn't change anything much... Why I have no > idea, it was passed to the build process... hmm, that's weird, are you sure you didn't make a mistake somewhere? -Bsymbolic can't have no effect and a rather visible effect at the same time ;-). for profiling: http://www.gnu.org/software/binutils/manual/gprof-2.9.1/gprof.html basically, you need -g -gp in CFLAGS then run apache which will produce an output that have to be interpreted by gprof. you have to do this for both the PIC and non-PIC mod_php so we can compare. as for the actual benchmarks, i'm more interested in macrobenchmarks like this Smarty Demo that was mentioned in one of the URLs (and shows an impossible result btw, a statically linked in non-PIC mod_php can't possibly be slower than a non-PIC shared library), not microbenchmarks.
> hmm, that's weird, are you sure you didn't make a mistake somewhere? -Bsymbolic > can't have no effect and a rather visible effect at the same time ;-). Yeah I'm aware this sounds absurd... But it's what's happening, just to be sure I compiled PHP another time, Apache was using the newly compiled mod_php, and -Bsymbolic was added during the compile. But the results remained on an average of about 30.580 seconds, still much more than the 29.637 seconds of the first series of benchmarks I've done. So maybe it wasn't really -Bsymbolic, but just some outside influence of something else that changed the values of my first benchmarks, or exactly the contrary and something influences the values of my current benchmarks? Boh, no clue on this, the testing environment remained the same, the only application that got restarted is Apache to load the new mod_php... But -Bsymbolic or not, PIC seems to hit PHP quite hard, and from what I understand profiling may help us track what slows it down, right? > for profiling: http://www.gnu.org/software/binutils/manual/gprof-2.9.1/gprof.html > basically, you need -g -gp in CFLAGS then run apache which will produce an > output that have to be interpreted by gprof. you have to do this for both the > PIC and non-PIC mod_php so we can compare. as for the actual benchmarks, i'm > more interested in macrobenchmarks like this Smarty Demo that was mentioned in > one of the URLs (and shows an impossible result btw, a statically linked in > non-PIC mod_php can't possibly be slower than a non-PIC shared library), not > microbenchmarks. Ok I'll do that tomorrow when I have time. Btw what Smarty Demo are you referring to? Couldn't find that in the URLs from Andreas. For macrobenchmarks I could simply set up a phpMyAdmin or some webapp and let the Apache benchmark suite test how long it takes for 1000 index.php's to show up, then change mod_php and do it again, that's also how it was done in one of the links. I'd then anyways profile both the macrobenchmark and the microbenchmark, since while not being really "real-world" proof, it shows a serious drop in performance and can show what is causing it imo. I'll then put the data from the profiler somewhere for you to download and have a look at. Thanks for all the help! :) Best regards, CHTEKK.
George mentioned it in his benchmark results: http://www.omniti.com/~george/php/stats2 I think he's talking about the sample guestbook from smarty manual: http://smarty.php.net/sampleapp/sampleapp_p1.php Many people use it for benchmarking, because it loads a lot of code, similar to "real world" applications. Another application often used for benchmarks like that is phpMyAdmin (frontpage), which loads/executes even more "real world" PHP code. (e.g. http://turck-mmcache.sourceforge.net/index_old.html#bench)
Update on this: sorry, I really haven't time atm to do profiling etc., so for now we introduced an interim solution: the "pic" USE flag. Old-style PHP will not be changed, I don't want to change it's behaviour, and it will go away in 2-3 months anyway. For the new dev-lang/php ebuilds, like I said, we added the "pic" USE flag wich enables/disables "--with-pic", that way it will work on non-Hardened systems fast but with TEXTRELs, on Hardened-systems "pic" is turned on by default, so it will work slower but without TEXTRELs, and in any case the user has the possiblity to toggle the flag, so if you use a PaX kernel on a non-Hardened system, simply enable the "pic" USE flag and it will work again without TEXTRELs. Best regards, CHTEKK.
*** Bug 115258 has been marked as a duplicate of this bug. ***
*** Bug 116069 has been marked as a duplicate of this bug. ***
Lares reported textrels in dev-php/mod_php-4.4.0-r9: TEXTREL usr/lib/php/extensions/no-debug-zts-20020429/java.so TEXTREL usr/lib/apache2/modules/libphp4.so the java.so one hasn't been mentioned here before.
not strictly related to mod_php itself, but apply to the module for apache2 provided by dev-lang/php-5.1.1. It also have TEXTREL TEXTREL usr/lib/apache2/modules/libphp5.so
dev-php/mod_php is gone from the tree now, dev-lang/php remains with the USE flag "pic" to fix the TEXTRELS: enable it and you'll get a TEXTREL free PHP (java extension too here), but at the cost of it's speed. Best regards, CHTEKK.
Sounds like this is fixed then.
*** Bug 148459 has been marked as a duplicate of this bug. ***
*** Bug 148554 has been marked as a duplicate of this bug. ***
*** Bug 203221 has been marked as a duplicate of this bug. ***
*** Bug 210598 has been marked as a duplicate of this bug. ***
