Gentoo's glibc strips fomit-frame-pointer. It then configures the build normally, and adds an option to the configure script to disable lazy bindings (enable-bind-now). There's an option, enable-omitfp, that builds the libraries without a frame pointer. We should make a use flag out of that. For instance, glibcomitfp. That way, glibc will be built with the enable-omitfp option, and fomit-frame-pointer will not be stripped. On the glibc website, it says that the gains are negligible. That is DEFINATELY not the case. As of editing the ebuild to include this change, my computer is flying. Normally, when I compile something in the background (something as big as mysql), I can't do anything else. My computer is pretty old, a celeron. But using my new glibc, I can compile mysql, browse web pages, type bug reports like this, and everything is flying. My performance gains are about 30%-40%, or at least that's what it feels like. Another thing is that a glibcprofiling flag should be introduced, that allows users to build glibc with the profiling libraries, in case anyone wants to do profiling. In case anyone argues that the omitfp option will make debugging impossible, glibc builds a set of non-omitfp libraries so that you can debug. If my ebuild would help, I'll post it. But these changes are pretty easy to make. Reproducible: Always Steps to Reproduce:
Forgot to add, there should be another flag for whether users want lazy binding or not.
Gaining ONE register will not give youu a 40% performance increase, but I'll consider this for the -r1 revbump
It seems to work just fine with --enable-omitfp. I have compiled glibc-2.3.4.2005....-r1 with it, and had no errors with it, but a speed increase. Some .a files are significantly smaller. The USE-Flag could ba named omitfp, since this name is not to be mistaken . The filter-flags fomit-frame-pointer statement may also become conditional, but the configure script of glibc may take care of the adding fomit-frame-pointer. BTW., is there any opportunity to add -Os as an option for nptl/nptlonly-users like me? That is to say, make the -O2 for linuxthreads conditional (if use !linuxthreads).
How about letting it be controlled by the debug use-flag: use !debug && myconf="${myconf} --enable-omitfp" I think most people that don't do any debuging would want this.
Well, the -debug use-flag may get involved, but from my point of view as an option to delete all the .og or .ag files(those debuggable libraries), not to control the building of the libraries without frame-pointer itself, though a -debug might be necessary to use omitfp. Something like: if use omitfp && if use !debug rm *og rm *ag fi before merging. Of course this is maybe something for ~x86, and a hardmask for quite a while.
I think that we should just have a omitfp use flag. If you could build glibc without the debugging stuff, and with a highly optmized, web site says its unstable, library, that could make people's lives pretty miserable. I'm for just having a: use omitfp && myconf="$myconf --enable-omitfp" && append-cflags fomit-frame-pointer
@Kaiting: --enable-omitfp will automatically append -fomit-frame-pointer where it's safe so so I don't think portage should do that.
Ok. But my point is, we shouldn't remove the debug libraries. Maybe we could make a seperate use flag for that. The debug libraries should stay on the system so the devs don't go through hell every time someone files a bug.
Ok, for the -fomit-frame-pointer issue, we now enable the configure option before stripping the CFLAG. This should be the "safe" way to kill the frame pointer. I'm thinking we should also only do this if we are '! use debug', but I'm on the fence about that one... Would you guys mind testing out this logic. Just --sync up in an hour or so and emerge glibc with -fomit-frame-pointer in CFLAGS (check the ChangeLog to make sure you've got the latest ebuild)
I did emerge it, and my system is still alive. The option --omit-fp was used, there are again the files .a and the _g.a files(sorry, i don't have them here). the system is as fast as with my own, selfmade version. Still this solution is from my point of view not optimal. I think stripping -fomit-frame-pointer should be left in the ebuild, and then glibc can be configured with -enable-omitfp, so glibc puts in -fomit-frame-pointer where appropriate. I agree with Simon Strandman here. And still i would ask for -Os as an option with +nptl and +nptlonly, since it is said only linuxthreads requires -O2. Of course -O3 and -O>3 should be filtered, too. The user should also be given the choice to remove all libraries compiled with debug-information (the ones with an extra g in the name). An extra USE-flag and a big warning should be enough. These libraries are not used at all, everything is linked against the libraries without debug information, so they don't help at all. This is just an opinion, i do not have that much knowledge about that.
-fomit-frame-pointer IS stripped out of the CFLAGS, still. If it was originally in the user's CFLAGS (before being stripped), then the --enable-omitfp option is passed where appropriate. I fail to see how this logic is different from what you suggest. As for -Os... I don't want to allow that. Glibc is far too critical to allow -Os or -O3... and while it might work ok with some gcc builds, it will probably break others. I don't want to be responsible (even remotely) for tracking down that breakage. As for the debug option, I thought USE=debug handled that... I'll look into it some more
As for -fomit-frame-pointer, this should be no issue anymore, since the manpage of gcc states that this option is Enabled at levels -O, -O2, -O3, -Os. Concerning -Os, as far as i understand the manpage of gcc, -Os even uses less optimizations than -O2, so being conservative here would mean to me -O or -Os. Still, i am no developer, nor do i think i have the skills to be one, and since i did not find any information about whether -Os is risk free on the internet (i mean google), leaving it as it is now is fine with me, and probably with most Gentoo-ers out there. All the others, especially the ricers, still can edit the ebuilds as they need it.
-fomit-frame-pointer is only enabled for -O and up on arches where it doesen
-fomit-frame-pointer is only enabled for -O and up on arches where it doesen´t mess up debuging. So it's not on x86. The reason why I think omitfp should be enabled by !debug and not CFLAGS is because it does not only turn on -fomit-frame-pointer but also -O99 optimizations (I know it's weird) and -g0. Anyway, glibc-2.3.4.20050125-r1 works perfectly on my amd64 with omitfp.
@ Simon Strandman : I knew that once, but forgot about it in between. Now i remember the reason why i have fomit-frame-pointer in my CFLAGS ;) . The -O99 should be no problem(at least with the normal ebuild appending -O2). With some hacked ebuild (like mine, where i try to preserve -Os by not appending -O2) it may cause a problem if -O(1,2,3,s) is not defined. I also agree on that -enable-omitfp should not be en/disabled only by checking for fomit-frame-pointer. IMHO it should get it's very own use flag, since it is a quite major change in the build-process and the structure of the libraries, and some people would not want to use it. There is still some room in the IUSE line of the glibc ebuild. And with the issue that fomit-frame-pointer is included in -O(2,3,s) on some architectures, and on some it's not, it is probably not that logical that --enable-omitfp is added by a routine that is depending on this explicitely.
--enable-omitfp does cause build failures (bug #87697) but it's only on i386-pc-linux-gnu (I don't know about i486 or i586 but they are rarely used). On i686 and other CHOST's it seems fine. The ebuild should be updated to not --enable-omitfp if the CHOST is i386, and possibly i486 and i586 too!
Well, i do have a i586 with the newest glibc-2.3.5, and it compiled fine, using nptl(only). The system is running fine, too. It seems the bug you, Simon, mentioned is for i386-computers without mmx-extension, so probably i386 and i486 computers should not be allowed to use linuxthreads and --enable-omitfp together. BTW, i recently recompiled glibc-2.3.5 on my i686 with lazy-bindings and omitfp, and it is working fine. Fast, responsive, no errors yet, only arts is sometimes having his error(overload), but that is arts.
I'll add in the USE flag support to 2.3.5-r1 and 2.3.5.XXXXX. If you guys want to make me a patch for it, that'd help out, too.
ok, so we can get rid of the debug USE flag and just make the logic based on the glibc-omitfp USE flag... also, I don't want to give Joe User a way to make a lazy binding glibc, so if you want that, you can just do EXTRA_ECONF="--disable-bind-now" emerge glibc
yeah, joe blow should not screw around with bind settings, especially on the system libc
ok, fixed in 2.3.5-r1 which is in cvs now (but still in p.m since it's not 100% done yet)
The new use flag probably doesn't do what most people would "expect" for anyone using -Os. http://www.mail-archive.com/lfs-chat@linuxfromscratch.org/msg00076.html
