{"id":146,"date":"2013-02-03T02:34:10","date_gmt":"2013-02-03T02:34:10","guid":{"rendered":"http:\/\/blog.mozilla.org\/nfroyd\/?p=146"},"modified":"2013-02-03T02:34:10","modified_gmt":"2013-02-03T02:34:10","slug":"gcc-version-comparison-part-1-5n-corrections","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nfroyd\/2013\/02\/03\/gcc-version-comparison-part-1-5n-corrections\/","title":{"rendered":"gcc version comparison, part 1.5\/n: corrections"},"content":{"rendered":"<p>In <a title=\"gcc version comparison, part 1\/n: libxul sizes\" href=\"http:\/\/blog.mozilla.org\/nfroyd\/2013\/02\/01\/gcc-version-comparison-part-1n-libxul-sizes\/\">my previous post<\/a>, I discussed the size of libxul as compiled by various versions of GCC.\u00a0 Due to some configuration quirks, it turns out that the comparison was flawed.<\/p>\n<p>To recap: GCC versions 4.5-4.7 contained, among other things, vtables and their associated relocations for classes that were never instantiated.\u00a0 I theorized that some compiler optimization must have been responsible for this, and that this compiler optimization must have gotten disabled in those versions.\u00a0 Thinking about it afterwards, it turned out that there was a simple way to check this theory: examine the object files for the vtables.\u00a0 Some objects compiled by versions 4.5-4.7 must have the vtables, and no objects from versions 4.4 and 4.8 should contain the vtables.\u00a0 So let&#8217;s check, using <code>nsIDOMSVGTextElement<\/code> as an example:<\/p>\n<pre>[froydnj@cerebro froydnj]$ for d in 4 5 6 7 8; do\r\n  for o in $(find build-mozilla-gcc-4${d}\/ -name '*.o'); do\r\n    if readelf -sW $o |c++filt| grep -q 'vtable for nsIDOMSVGTextElement' 2&gt;\/dev\/null; then\r\n      echo $o; readelf -sW $o |c++filt|grep 'vtable for nsIDOMSVGTextElement'\r\n    fi\r\n  done\r\ndone\r\nbuild-mozilla-gcc-44\/content\/svg\/content\/src\/SVGTextElement.o\r\n   971: 0000000000000000   856 OBJECT  WEAK   HIDDEN  450 vtable for nsIDOMSVGTextElement\r\nbuild-mozilla-gcc-45\/content\/svg\/content\/src\/SVGTextElement.o\r\n  1241: 0000000000000000   856 OBJECT  WEAK   HIDDEN  676 vtable for nsIDOMSVGTextElement\r\nbuild-mozilla-gcc-46\/content\/svg\/content\/src\/SVGTextElement.o\r\n  1021: 0000000000000000   856 OBJECT  WEAK   HIDDEN  498 vtable for nsIDOMSVGTextElement\r\nbuild-mozilla-gcc-47\/content\/svg\/content\/src\/SVGTextElement.o\r\n  1075: 0000000000000000   856 OBJECT  WEAK   HIDDEN  533 vtable for nsIDOMSVGTextElement\r\nbuild-mozilla-gcc-48\/content\/svg\/content\/src\/SVGTextElement.o\r\n   831: 0000000000000000   856 OBJECT  WEAK   HIDDEN  532 vtable for nsIDOMSVGTextElement<\/pre>\n<p>So <strong>all<\/strong> versions of the compiler are generating the vtables that are sometimes present and sometimes not in the compiled libxul.\u00a0 Why do the vtables sometimes disappear?<\/p>\n<p>The linker on Linux systems has a <tt>--gc-sections<\/tt> option that eliminates unused sections from the final output file, using a form of <a href=\"http:\/\/en.wikipedia.org\/wiki\/Garbage_collection_%28computer_science%29#Basic_algorithm\">mark and sweep garbage collection<\/a>.\u00a0 Normally, this is not terribly effective, since all of your program code goes into <tt>.text<\/tt> (resp. data into <tt>.data<\/tt> and so forth), and something in .text ought to be getting used.\u00a0 But Mozilla is compiled with the options <tt>-ffunction-sections<\/tt> and <tt>-fdata-sections<\/tt>; <tt>-ffunction-sections<\/tt> gives each function its own uniquely named section and <tt>-fdata-sections<\/tt> does a similar thing for variables.\u00a0 Using <tt>--gc-sections<\/tt> with the linker, then, effectively eliminates unused functions and\/or variables that the compiler can&#8217;t prove are unused.\u00a0 (The compiler can eliminate unused static variables from a compilation unit, for instance, but eliminating unused variables that are visible outside of a compilation unit requires the linker&#8217;s help.)\u00a0 And indeed, the linking process on Linux uses this <tt>--gc-sections<\/tt> option.<\/p>\n<p>&#8230;most of the time.\u00a0 Depending on the vagaries of the GCC compiler version and the version of the linker being used, using <tt>--gc-sections<\/tt> can impede the debugging experience.\u00a0 So <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=670659\">bug 670659<\/a> added <a href=\"http:\/\/mxr.mozilla.org\/mozilla-central\/source\/build\/autoconf\/compiler-opts.m4#142\">a check<\/a> to disable <tt>--gc-sections<\/tt> if using that option altered the debugging information in unhelpful ways.<\/p>\n<p>You can probably see where this is going: on my machine, GCC versions 4.5-4.7 failed this check and so the <tt>--gc-sections<\/tt> option was not used with those versions.\u00a0 (GCC 4.8 actually wound up <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=837445\">bypassing the check altogether<\/a>.)\u00a0 Unfortunately, compiling things so the <tt>--gc-sections<\/tt> option is consistently used is <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=837446\">difficult because of how configure.in is structured<\/a>.<\/p>\n<p>Lesson learned: double-check your experimental setup before analyzing your results!\u00a0 Make sure everything&#8217;s being done consistently between your test configurations so your measurements accurately reflect differences in what you&#8217;re measuring.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In my previous post, I discussed the size of libxul as compiled by various versions of GCC.\u00a0 Due to some configuration quirks, it turns out that the comparison was flawed. To recap: GCC versions 4.5-4.7 contained, among other things, vtables and their associated relocations for classes that were never instantiated.\u00a0 I theorized that some compiler [&hellip;]<\/p>\n","protected":false},"author":320,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/146"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/users\/320"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/comments?post=146"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/146\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/media?parent=146"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/categories?post=146"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/tags?post=146"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}