I enabled dead code stripping in the nightly builds a month or three back and it has a noticable affect on the size of the generated disk image. The disk image for a release build of universal binaries drops by around 250KB, while the uncompressed frameworks drop by around 1MB. It would be nice if we could determine precisely what dead code is dropped, but failing that I think smaller binaries are always a nice idea.
Created attachment 10027 [details] Patch This enables dead code stripping in the Release configuration and turns on the full debug symbols that they require.
(In reply to comment #0) > It would be nice if we could > determine precisely what dead code is dropped, but failing that I think smaller > binaries are always a nice idea. Would it be possible to compare the output of nm(1) on the binaries and/or frameworks to determine what has been stripped? Or does this option strip smaller blocks of code like branches that are never reached as well?
Created attachment 10030 [details] List of stripped symbols
Created attachment 10031 [details] List of stripped symbols (unmangled)
An inspection of the output has revealed that RenderTextArea is completely stripped as it is unused (bug 10399). I'll see what other interesting things GCC has decided aren't used.
Comment on attachment 10027 [details] Patch This looks good to me. I'd like to see this in the Production configuration too. Could you explain the GCC_DEBUGGING_SYMBOLS = full part? Does that have any effect on the generated code? Why isn't the default OK?
From: http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeUserGuide/Contents/Resources/en.lproj/05_08_bs_linking/chapter_35_section_9.html "You must also compile the object files with the -gfull option to ensure that the resulting binaries can be properly debugged." "Note: The GCC compiler’s -g option normally defaults to -gused, which reduces the size of .o files at the expense of symbol information. Although the -gfull option does create larger .o files, it often leads to smaller executable files, even without dead-code stripping enabled."
Will this strip API calls that are "unused" in the framework but need to be there for external software that links to the framework?
(In reply to comment #8) > Will this strip API calls that are "unused" in the framework but need to be > there for external software that links to the framework? No. Exported symbols will not be stripped.
Created attachment 10048 [details] Updated patch Updated to include changes to Production configuration.
Landed in r15893.
This patch has caused a build failure in Release mode. Build errors out with cc1objplus: error: -fsave-repository may only be used with STABS debugging. Apparently the patch was made before DWARF was reenabled on the Release and Production builds.
(In reply to comment #12) > This patch has caused a build failure in Release mode. Build errors out with > cc1objplus: error: -fsave-repository may only be used with STABS debugging. > Apparently the patch was made before DWARF was reenabled on the Release and > Production builds. Which build file(s) does this option appear in, or what's the build command that breaks? I don't see it anywhere, and http://build.webkit.org/ seems fine.
David, Timothy landed my build fix before the buildbot had a chance to break. See http://trac.webkit.org/projects/webkit/changeset/15897 for the fix.