On Fri, Apr 05, 2013 at 07:31:55PM +0530, Dhiru Kholia wrote: > On 04/04/13 at 09:26am, Steve Grubb wrote: > > On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote: > > > On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb <sgrubb@xxxxxxxxxx> wrote: > > > How much does it (PIE) slow things down? I'm fairly certain you don't have any > > > good data on this point. Dhiru is working out how to best figure out FWIW. > > > > > > I'm willing to agree that PIE on x86 is going to be very slow due to > > > register pressure. However, we should consider revisiting what we want > > > built as PIE. Is Firefox a long running process? > > > > Firefox fits into the category of a parser of untrusted media. Therefore it > > should hardened. > > FWIW, Ubuntu has been shipping PIE enabled Firefox for years now. > > https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.1/+bug/507744 > > I repeated the benchmarks (mentioned in the above bug report) for > Firefox 20.0 running on Fedora 18 64-bit. Firefox as benchmark doesn't look like a good idea (and I'm really surprised that we don't compile it as PIE, I thought we've been doing that for years). The special thing on firefox is that it is really tiny binary (< 64K of .text) with almost no libraries linked directly (just -lc, -ldl, -lstdc++, -lpthread and their dependencies (-lm, -lgcc_s)), so indeed the relocation processing isn't very expensive (only ~ 130 relocations) before reaching main and prelink can't make it significantly faster. Firefox is designed to dlopen all of its code from main and later on, something prelink doesn't significantly improve (the only improvement could be if all/some of those dlopened libraries were prelinked (or just prelink -R relocated) to picked up addresses, then it could avoid relative relocation processing). Even just starting firefox to show up a window shows around 8000 relocations though, but except for the first ~ 130 everything is during dlopen. If you want to benchmark something where it makes a difference, you want to benchmark some program where the binary contains significant amount of code, and which links against lots of shared libraries, or stuff like configure scripts or similar usage scenarios where are thousands of small short running programs spawned each second and where the relocation processing consumes significant amount of time. Jakub -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
