http://bugzilla.xfce.org/show_bug.cgi?id=5887
--- Comment #14 from Brian J. Tarricone <[email protected]> 2009-10-22 14:50:36 PDT --- Is it actually hard to measure? It's true that I don't really want to change it because what we have seems to work fine, and there's some risk in changing it. But it's a question of the benefit: if you're going to propose a change, then the burden is on your shoulders to prove that there's actually a benefit. Do you know how to benchmark this? If not, then you're just making a baseless claim about some unknown performance case. The only evidence of improvement you've provided is a 6% decrease (less than 2kB) in binary size for a single (relatively small 260kB) library. Not only is it an unreliable sample, I just don't think saving 6% (assuming it's 6% for every single library, which I doubt) of our total shared library footprint is all that impressive. If you prefer to use --version-script, why not just generate the .ver file from the .symbols file (or vice versa)? Also note that -Bsymbolic isn't about reducing PLT entries. It does do that as a side-effect, but its purpose is to bind symbol definitions so they can't be overridden. The modern/correct way of defining the public ABI is through visibility attributes. The version script method is also correct, though maybe "the old way" (not that there's anything wrong with that). -Bsymbolic has nothing to do with ABI. The safest way to reduce PLT entries is with the aliasing trick. Performance wise, I can't really say too much, but I'd guess there's less of a win here than you'd think. To call shared lib functions, the application *still* has to call into the GOT. Just with -Bsymbolic, instead of resolving the function address with GOT+PLT, it should get resolved with GOT+a static offset. This offset still needs to be determined, so you're not speeding up initial application load time (the relocation still has to happen anyway). As for actual calls to the function, I'm not sure how the runtime linker handles this. Either it will more or less generate a PLT on the fly (which is why the .so size is smaller), or it'll patch references in the binary at callsites with GOT+offset either at load time or on first call. If it does the former, I don't think there's really any benefit. If the latter, successive calls to the function should be faster, but I'm not sure how much. Anyway, that's all hand-wavy from memory and intuition (haven't looked at this stuff in years), so I might be off on how that works. But still, that doesn't really change the fact that the benefit seems negligible (pending proof either way), and what we have works well enough already. Now, if you're saying the alias stuff is a pain to set up, I'd certainly agree. But that doesn't justify throwing away the stuff that's already set up. I believe the script that generates the alias .c/.h files is in perl... if that could be rewritten in portable sh, we could stuff that in x-d-t as well, and then just require that the maintainer: 1. Put the macro in configure.ac 2. Maintain a file with a list of exported symbols 3. Put a rule substitution in the Makefile.am (similar to @INTLTOOL_DESKTOP_RULE@) that generates the alias .c/.h files 4. Include the files in the appropriate .c files. That would maintain the status quo with regard to functionality, but make setting up new libraries easier. The only annoying bit is #4, but maybe we can come up with a workaround for that, too. -- Configure bugmail: http://bugzilla.xfce.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Xfce-bugs mailing list [email protected] http://foo-projects.org/mailman/listinfo/xfce-bugs
