I'm not sure how feasible this is. There are users who try to add "-fomit-frame-pointer" to their CFLAGS for what is believed to be a performance benefit. My understanding of GCC compiler options is not great, but I believe this makes debugging somewhat difficult. In my particular case, when Java VMs crash, the dump they provide seems to be missing the library and function name. It would be nice if users were warned that filing upstream bugs from such a system is difficult, and that they might be asked to recompile their whole system. The particular case I'm talking about is Eclipse's Bug 76586 ("https://bugs.eclipse.org/bugs/show_bug.cgi?id=76586"). While I know of a few possible conditions that can cause crashes on start-up (e.g., unifont+pango interactions), it is impossible to tell if this is the source of the crash described in the bug. Normally, to diagnose such a problem I would look at the function and library name. Whether or not the Gentoo teams feels a warning (when emerging, perhaps) is inappropriate, it would still be nice to have more information about this particular gcc compile option. In particular, I'm curious about two things. First of all, with examples, how much debugging information is destroyed (i.e., is my Java VM dump case caused by this)? Secondly, what kind of performance benefit can users expect to gain? It would nice to see a small suite of performance tests showing the performance differences. I feel such an article linked from "gentoo.org" would be very helpful to the Gentoo user base. Also, note that "http://gentoo-wiki.com/Safe_Cflags" is encouraging users to user "-fomit-frame-pointer".
I can attest to this problem not only in the case of Eclipse, but many other desktop-related applications. In fact, many applications even though they are primarily written in Java, will have parts connecting them to the standard C libraries (gtk+, motif, gmp, GNOME, ...). When these applications crash, we get the stack trace for the Java part, but not for the C part if the upstream libraries have been compiled with -fomit-frame-pointer. I suggest we either make prominent in the installation guide that -fomit-frame-pointer is strongly discouraged, or even add Portage warnings about it.
Would something along the lines of """ There are a few optimization flags (like -fomit-frame-pointer) that make debugging more cumbersome. Please try to avoid them if you think on submitting bugreports and asking for help. """ be sufficient? I must say though, that I don't believe many users read the part in the installation instructions regarding CFLAGS editing. I might be wrong though...
I guess I'm hoping for something a bit more than a line in the install guide. This won't affect the current user base, and might be overlooked even by new users. The problem is one of re-educated the existing user base. As such, either a well-advertised article or a portage warning might be more appropriate. But the more I think about it, the more I feel that people don't read portage warnings either....
Isn't that up to the users? I mean, if we receive a bugreport with an undebuggeable trace, we have all the right to claim "recompile with -O2 -march=i686 -pipe" first, as is already mentioned in the FAQ (http://www.gentoo.org/doc/en/faq.xml#optimizations). I hope you don't expect Gentoo to strip -fomit-frame-pointer on every emerge by itself. That's not really "flexibility" anymore.
Also, see Eclipse's Bug 71804 ("https://bugs.eclipse.org/bugs/show_bug.cgi?id=71804") and Bug 76551 ("https://bugs.eclipse.org/bugs/show_bug.cgi?id=76551"). Possibly Bug 63524 ("https://bugs.eclipse.org/bugs/show_bug.cgi?id=63524") as well. Also browse the Gentoo forums. For example, "[HOWTO] Flying with Gentoo" ("http://forums.gentoo.org/viewtopic.php?t=231170") or "-fomit-frame-pointer - Is this needed? [SOLVED]" ("http://forums.gentoo.org/viewtopic.php?t=238985") I guess my main concern is that I feel time is being wasted -- time spent by Gentoo users, and time spent by upstream package maintainers. I'm trying to suggest some ways I think we might be able to further reduce the amount of wasted time. The primary concern here is one of education -- making sure the accurate information reaches the Gentoo user base, and that misinformation is minimized. I also feel that the over aggressive use of CFLAGS is one of the things that reflects poorly on Gentoo as a community. In attending the Desktop Developers' Conference and the Ottawa Linux Symposium this year, it seemed that everyone loved to make fun of the Gentoo project. It was all in good humour, but I think it comes back to maintainers of other projects having to deal with Gentoo users who don't understand CFLAGS. One way thing that might help is an article discussing CFLAGS and their effects. In particular, I have a personal interest in seeing what kind of performance benefit can be gained with "-fomit-frame-pointer" as compared to what kinds of problems it can cause. A thorough article might not be read by everyone. However, the people that do read it would be able to better advise other users -- on forums, bug reports, the Wiki and IRC. This is really as much a P.R. effort, as it is an attempt at education. I don't feel stripping CFLAGS is a good idea either. I use Gentoo because I have the freedom to do what I want, and I don't want this freedom taken away.
I totally agree on a decent document that explains the virtues of various, popular compiler optimization settings. *However*, I've tried to start one numerous times and always came to the conclusion that it's impossible because the optimizations are highly dependent on the type of tool you are compiling. This might be something that the gentoo-performance team wants to take a stab at.
It is difficult, as the optimizations will have different effects depending on how the code is written. However, I'm not really asking for an exhaustive view of its varying effects. More of a rough idea. Taking several sample applications and showing the effects would be interesting. Once the document is started and publicly available, I'm sure users and developers would contribute other statistics and information for inclusion.
Also see "https://bugs.eclipse.org/bugs/show_bug.cgi?id=67219#c13".
What will we do about this? I can leave it linger here for 1 month, then mark it as LATER and put it out on our "Requested Documentation" stuff, but that's about it. And I don't know any person willing to start a GCC Optimization Guide (especially since we don't want to let our users believe we're only here for ricers). I'll add in the installation instructions that the use of -fomit-frame-pointer might have serious repercussions on the debugging of applications.
Told ya...
(In reply to comment #4) > Isn't that up to the users? I mean, if we receive a bugreport with an > undebuggeable trace, we have all the right to claim "recompile with -O2 > -march=i686 -pipe" first, as is already mentioned in the FAQ > (http://www.gentoo.org/doc/en/faq.xml#optimizations). > The FAQ needs to be amended to say "recompile with -O2 -march=i686 -pipe and no "-fomit-frame-pointer" before submitting bugs." ATM it just says There is a Safe CFLAGS doc at http://gentoo-wiki.com/Safe_Cflags which I have amended to include a warning about this, and a link to this bug. Does this count as a doc? > I hope you don't expect Gentoo to strip -fomit-frame-pointer on every emerge by > itself. That's not really "flexibility" anymore. > Agreed; it does improve performance (by giving gcc an extra register, which is important on x86 as there are few regs available.)
no, the FAQ is not about submitting bugs ... we have a bug submitting guide for that ... plus those CFLAGS wont work on any non-x86 host we do not link to gentoo-wiki.com because it's a wiki and there's no way for us to verify the integrity of the pages
*** Bug 154850 has been marked as a duplicate of this bug. ***
Trying to re-open this topic. I'd really like to. Copied from 154850 We already had a bug about a 'official' cflags guide like 3 years ago and I think it's about time to re-open effort on this topic. I'm talking about adding more detailed information within the handbook about things not to do within gentoo. As the handbook provides only very little cover on this, people crowd together on gentoo-wiki.com/forums.gentoo.org/#gentoo and provide bogus information regarding ~arch and cflags. I use to be in #gentoo and at least 2/3 of the question arising are based on people running completly in ~arch or having bogus cflags. This IS a problem; not only to the community with it's little resources on providing useable solutions (80% of the patches in the tree are done by like 20% of the people involved) but also for the developers and the distribution itself. Gentoo - as a brand - should make a clear point about how it organizes itself, that people are neither supposed not supported in ~arch and that users are not ment to -eD world because they found out about -fomgfast. I'm not talking about locking people out of the development process (aka hiding ~arch from them) or redefining Gentoo. The current noise ratio in the community, produced by the community is - as far as I see - very high. Gentoo, imho, is currently the 'freeist' linux distribution, talking about 'free' not as in 'beer' but as in 'freedom'. I can see the code, I can download the code and I can compile the code. This is neither about speed/performance but about trust and I'd love to see people trust Gentoo. So after this preamble, some concrete proposals: * It's currently very hard for an average, especially new user to inform himself about the current development status. That is, there should be a central place on gentoo.org for certain hot topics like important packages going to stable arch. * ACCEPT_KEYWORDS="~arch" should be possible but not be considered good behaviour and treated as such. A single message in 'emerge' telling people about keywording only specific packages can do the job. * There is LOTS of noise about the CFLAGS. People give each other tips on setting stuff like -ffast-math, not realizing ebuilds do lots and lots of cflags filtering. There should be 'official' information, more specific than they currently are, on the cflags. There had been a gwn topic about that once, that needs to be within the handbook. Also the ebuild cflags-strip function should ewarn about cflags being stripped so users get the point.
(In reply to comment #14) > Trying to re-open this topic. I'd really like to. > > Copied from 154850 ebfe, we read our bugreports, so there's no need to copy stuff from one to another. > As the handbook provides only very little cover on this, people crowd > together on gentoo-wiki.com/forums.gentoo.org/#gentoo and provide bogus > information regarding ~arch and cflags. Got a patch we can talk about or at least a bit less vague suggestion than "current amount information is not sufficient"? > * It's currently very hard for an average, especially new user to inform > himself about the current development status. That is, there should be a > central place on gentoo.org for certain hot topics like important packages > going to stable arch. Watch arch aliases on Bugzilla :). Now seriously - as you can see, nobody from current development team wants to maintain such a page. It's perfectly possible that a lot of users would benefit from it. If you think it's worth *your* time, just add arches to your bugzilla watchlist and make such a page yourself. Try to maintain it for several months and if it works well, you'd prove that it was a great idea. The problem is that Gentoo doesn't have unlimited manpower, thus if you feel that something should be done and nobody did it yet (and neither is willing to), you'd have to do it yourself. > * ACCEPT_KEYWORDS="~arch" should be possible but not be considered good > behaviour and treated as such. A single message in 'emerge' telling people > about keywording only specific packages can do the job. Gentoo Documentation Team can't do much about this. If you feel it's a good idea, talk to Portage guys and/or the -dev ML. > * There is LOTS of noise about the CFLAGS. People give each other tips on > setting stuff like -ffast-math, not realizing ebuilds do lots and lots of > cflags filtering. There should be 'official' information, more specific than > they currently are, on the cflags. There had been a gwn topic about that once, > that needs to be within the handbook. Also the ebuild cflags-strip function > should ewarn about cflags being stripped so users get the point. See above. Hope this helps...
(In reply to comment #4) > Isn't that up to the users? I mean, if we receive a bugreport with an > undebuggeable trace, we have all the right to claim "recompile with -O2 > -march=i686 -pipe" first, as is already mentioned in the FAQ > (http://www.gentoo.org/doc/en/faq.xml#optimizations). > > I hope you don't expect Gentoo to strip -fomit-frame-pointer on every emerge by > itself. That's not really "flexibility" anymore. > http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html#Optimize-Options Clearly state that "-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging." So why not cleary tell people to do not had it if they don't know what they are doing? I would also say the same for -g as if this is use without -fno-omit-frame-pointer on some machine it will interfer with debugging also. I talk by experience here, I even got segfault by using -g on some package can't recall which one but I never bug to repport them as it was my fault.
(In reply to comment #16) > Clearly state that "-O also turns on -fomit-frame-pointer on machines where > doing so does not interfere with debugging." So why not cleary tell people to > do not had it if they don't know what they are doing? Well on x86 especially it makes a difference to performance. The advice should just be (and I believe is) recompile with -O2 -march=whatever -pipe and no other flags to reproduce the bug before reporting, with a note that using -g for more info would also require -fno-omit-frame-pointer. The frame-pointer is needed for the stack-trace, which as user data is more usually supplied than gdb info, which the developer would typically generate himself. If -fomit-frame-pointer doesn't interfere with debugging, it'll be because the arch doesn't require it for stack traces, so there's no real need to worry about it for the usual case. Where gdb info is needed the dev can ask for a recompile with -g -fno-omit-frame-pointer, which as you pointed out is necessary.
It's been awhile, eh? Reopening. :) I'm writing up a guide that covers the basics of CFLAGS/CXXFLAGS optimization and the philosophy behind it. Note that I won't cover the individual flags available, since there are hundreds, and the GNU gcc manual already lists them. Basically, the guide will contain -march, -pipe, -fomit-frame-pointer (since that is common on the most common arches, x86 and amd64), and -O. Along with other stuff. Yes, I know, a whole guide just to say "Use only these four flags"? My goal is to do that, but also to talk about why ricing/aggressive CFLAG usage is bad. Already 150 lines into it, so.... Ideally, this would be something maintained by the GDP, rather than an unofficial" doc found only in my devspace. Once I post it, you be the judge.
About to post the first draft. Also CCing dirtyepic, since he's a GCC maintainer and knows a buncha stuff, I figure. :)
Created attachment 121094 [details] co-guide.xml Compilation Optimization Guide first draft. Critique away.
On some arches (x86), -mcpu and -mtune are synonyms (with -mcpu being the deprecated one). Statement that -fomit-frame-pointer is on by default is false.
(In reply to comment #21) > On some arches (x86), -mcpu and -mtune are synonyms (with -mcpu being the > deprecated one). > > Statement that -fomit-frame-pointer is on by default is false. > 1) -march/-mtune/mcpu: I already had a <note> block right after that bit advising the user to read the relevant section that highlighted the differences between those three, but I went ahead and added a bit to that <note> pointing out that "on some arches, such as x86, -mcpu is deprecated and -mtune should be used instead." 2) -fomit-frame-pointer being on by default: yes, it is. "On machines where doing so does not interfere with debugging", though the manual fails to specify which arches it is turned on as I explain in that section. Given how the flag behaves though, x86/x86-64 will need to have it added explicitly. I'm not sure about other arches, though I know that on VAX for instance it won't do anything at all. read the gcc manual: "-O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging." However, I took your evident confusion into account, and rewrote that sentence to make it more obvious: - It is turned on at all levels of <c>-O</c> (except <c>-O0</c>), but you... + It is turned on at all levels of <c>-O</c> (except <c>-O0</c>) on architectures where doing so will not interfere with debugging, but you... Thanks for the suggestions; added/clarified.
considering the very large majority of people who will read this are x86/x86_64 users, leaving the section vague isnt really a good idea omitting the frame pointer on x86 will affect debugging so it is not enabled by default on it
Created attachment 121413 [details] co-guide.xml Revised version, includes suggestions posted to the bug.
-mcpu and -mtune are identical; it was just a name change that happened during the 3.3 -> 3.4 timeframe. so the statement "c>-mtune</c> is even more generic than <c>-mcpu</c>" isn't correct. also, -mcpu is deprecated on ALL archs. everyone needs to be using -mtune, unless for some reason they're using GCC 3.3. i remember losing an argument once where i said -fomit-frame-pointer was not enabled by default on x86-64 with -O. turns out it is. > "Furthermore, <c>-momit-frame-pointer</c> has been shown to <uri > link="http://www.coyotegulch.com/products/acovea/aco5p4gcc40.html">negatively > impact</uri> code performance." Should be "-momit-leaf-frame-pointer" Do we have to link to acovea? ;P Otherwise, good job. ;D
(In reply to comment #25) > -mcpu and -mtune are identical; it was just a name change that happened during > the 3.3 -> 3.4 timeframe. so the statement "c>-mtune</c> is even more generic > than <c>-mcpu</c>" isn't correct. also, -mcpu is deprecated on ALL archs. > everyone needs to be using -mtune, unless for some reason they're using GCC > 3.3. This does not actually seem to be true for all arches; I first noticed this in the handbook. A good example is sparc; -mcpu is encouraged: "Set the instruction set, register set, and instruction scheduling parameters for machine type cpu_type" By contrast, here's what -mtune says: "Set the instruction scheduling parameters for machine type cpu_type, but do not set the instruction set or register set that the option -mcpu=cpu_type would." Clearly, on this arch, -mcpu is not deprecated, and in fact -mtune is more generic than -mcpu. GCC just seems to be a little screwy that way; it doesn't seem like -mcpu is deprecated for *all* arches yet. > i remember losing an argument once where i said -fomit-frame-pointer was > not enabled by default on x86-64 with -O. turns out it is. That might have even been lost to me, back in the day. ;) I used to argue that too, but given what I've since found out about how the flag works, I'm not so sure anymore. On x86 and x86-64, it frees up an extra register, right? So doesn't that mean that you've just given up all hope of real debugging because you've dropped the thing? I'm not so sure that x86-64 is any different from x86; AFAIK they work the same way. Losing frame pointer information seems to mean that you lose that debugging info regardless of which arch it happens on. Confirm? Y/N? > acovea What's wrong with acovea? Not good? I'd thought it was an okay way to check stuff -- I was interested in it primarily for actual performance benchmarks, but if it's considered unreliable/untrustworthy/half-assed/etc., then explain it! I'd have to remove it if that was the case. Thanks for your suggestions, mostly fixed in the next draft. :)
(In reply to comment #26) > Clearly, on this arch, -mcpu is not deprecated, and in fact -mtune is more > generic than -mcpu. GCC just seems to be a little screwy that way; it doesn't > seem like -mcpu is deprecated for *all* arches yet. You're right, I never noticed that before. Shows what I know. ;) > > i remember losing an argument once where i said -fomit-frame-pointer was > > not enabled by default on x86-64 with -O. turns out it is. > > That might have even been lost to me, back in the day. ;) I used to argue that > too, but given what I've since found out about how the flag works, I'm not so > sure anymore. On x86 and x86-64, it frees up an extra register, right? So > doesn't that mean that you've just given up all hope of real debugging because > you've dropped the thing? I'm not so sure that x86-64 is any different from > x86; AFAIK they work the same way. Losing frame pointer information seems to > mean that you lose that debugging info regardless of which arch it happens on. > > Confirm? Y/N? in gcc/config/i386/i386.c (which handles both x86 and x86_64), flag_omit_frame_pointer is set like so: /* The default values of these switches depend on the TARGET_64BIT that is not known at this moment. Mark these values with 2 and let user the to override these. In case there is no command line option specifying them, we will set the defaults in override_options. */ if (optimize >= 1) flag_omit_frame_pointer = 2; flag_pcc_struct_return = 2; flag_asynchronous_unwind_tables = 2; and in override_options is the following: /* Set the default values for switches whose default depends on TARGET_64BIT in case they weren't overwritten by command line options. */ if (TARGET_64BIT) { if (flag_omit_frame_pointer == 2) flag_omit_frame_pointer = 1; if (flag_asynchronous_unwind_tables == 2) flag_asynchronous_unwind_tables = 1; if (flag_pcc_struct_return == 2) flag_pcc_struct_return = 0; } else { if (flag_omit_frame_pointer == 2) flag_omit_frame_pointer = 0; if (flag_asynchronous_unwind_tables == 2) flag_asynchronous_unwind_tables = 0; if (flag_pcc_struct_return == 2) flag_pcc_struct_return = DEFAULT_PCC_STRUCT_RETURN; } so in a nutshell, with -O1 or greater flag_omit_frame_pointer is first set to 2. then if it isn't overridden by the user on the commandline, override_options sets it to 1 (enabled) on 64bit targets and 0 (disabled) on other x86 targets. > What's wrong with acovea? Not good? I'd thought it was an okay way to check > stuff -- I was interested in it primarily for actual performance benchmarks, > but if it's considered unreliable/untrustworthy/half-assed/etc., then explain > it! I'd have to remove it if that was the case. Well, there's nothing really wrong with acovea, but it hasn't really been accepted to be more than (interesting) theory. I'm not sure we can make practical judgments based on its conclusions. Also, it kind of contradicts what was stressed earlier in the document about not using ricer CFLAGS. "Oddball CFLAGS kill performance and break things. BTW, here's a page that's just packed with random crazyass flags you can mess around with." ;) This may just be my opinion. One other thing I've been thinking about: I think it would be helpful to our users if we had an official document listing the correct -march/-mcpu/-mtune/etc settings for every arch/subarch we run on (basically like the Safe CFLAGS wiki page[1]). Unlike the wiki it would be under our control meaning we could link to it in our docs (ie. this guide, handbook, etc). If anyone else thinks this is a good idea I'd be happy to write it. [1] http://gentoo-wiki.com/Safe_Cflags
(In reply to comment #27) > then if it isn't overridden by the user on the commandline, > override_options sets it to 1 (enabled) on 64bit targets and 0 (disabled) on > other x86 targets. Okay, I'll fix0r the draft for this, thanks for the info. > Well, there's nothing really wrong with acovea, but it hasn't really been > accepted to be more than (interesting) theory. I'm not sure we can make > practical judgments based on its conclusions. Also, it kind of contradicts > what was stressed earlier in the document about not using ricer CFLAGS. > "Oddball CFLAGS kill performance and break things. BTW, here's a page that's > just packed with random crazyass flags you can mess around with." ;) This may > just be my opinion. Good point....I'll have to rethink how I want to work that bit in. > One other thing I've been thinking about: I think it would be helpful to our > users if we had an official document listing the correct > -march/-mcpu/-mtune/etc settings for every arch/subarch we run on (basically > like the Safe CFLAGS wiki page[1]). Unlike the wiki it would be under our > control meaning we could link to it in our docs (ie. this guide, handbook, > etc). If anyone else thinks this is a good idea I'd be happy to write it. Eeek! I specifically did not want to include a list of suggested -march settings. I had started out with a table for figuring out "do I need SSE/MMX/etc." for x86 subarches, but I scrapped that in favor of users using their brains and click fingers to follow the links repeated throughout the guide. I'm also dead set against copying any content from that d**ned wiki, and even the ideas of the stuff that's found in the wiki... We have something like that as it is in each handbook, in the configuring /etc/make.conf chapter. We have suggested -march/-mtune/-mcpu for every arch. The only place that it'd get especially tricky is for x86 (and maybe ppc variants), since there is a plethora of subarches to choose from. I'm not in favor of such a list, and I know the GDP isn't in favor of copying the wiki's content. I can't think of any other way to get that same information into the doc, but I'm also not in favor of listing it, period. ;) Anyone else? Bueller? Bueller?
(In reply to comment #28) > I'm also dead set against copying any content from that d**ned wiki, and even > the ideas of the stuff that's found in the wiki... Umm, well, so there won't be any Xen guie because gentoo-wiki has it before us. Nice... > and I know the GDP isn't in favor of copying > the wiki's content. I can't think of any other way to get that same information > into the doc, but I'm also not in favor of listing it, period. Well, there are two reasons why we don't want to *copy* stuff from gentoo-wiki: a) possible copyright violation as we use different license b) copying broken stuff As we're discussing one simple table here, I don't think a) is valid, and as the whole problem is easily verifiable (/me looks at dirtyepic), b) is not an issue, either.
Created attachment 122366 [details] co-guide.xml Revised version. Comments out the inline reference to acovea (though I still cited my sources as I should in a comment), the link to it in the Resources section mentions that its flag suggestions are not appropriate for system-wide use. Other changes scattered throughout.
Nothing on this in a little while, so unless I hear otherwise, I'll be adding the doc to our repo shortly. Hmm, what categories...system administration?
Added to CVS: http://www.gentoo.org/doc/en/co-guide.xml Finally finished!
thanks to all, especially josh :->
found it at http://www.gentoo.org/doc/en/gcc-optimization.xml
