Bug 10394 - WebKit Release and Production configurations should enable dead code stripping
Summary: WebKit Release and Production configurations should enable dead code stripping
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Mark Rowe (bdash)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-14 17:16 PDT by Mark Rowe (bdash)
Modified: 2006-08-15 19:07 PDT (History)
4 users (show)

See Also:


Attachments
Patch (4.54 KB, patch)
2006-08-14 17:25 PDT, Mark Rowe (bdash)
no flags Details | Formatted Diff | Diff
List of stripped symbols (387.85 KB, text/plain)
2006-08-14 19:17 PDT, Mark Rowe (bdash)
no flags Details
List of stripped symbols (unmangled) (470.12 KB, text/plain)
2006-08-14 19:18 PDT, Mark Rowe (bdash)
no flags Details
Updated patch (5.96 KB, patch)
2006-08-15 16:14 PDT, Mark Rowe (bdash)
timothy: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Rowe (bdash) 2006-08-14 17:16:17 PDT
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.
Comment 1 Mark Rowe (bdash) 2006-08-14 17:25:14 PDT
Created attachment 10027 [details]
Patch

This enables dead code stripping in the Release configuration and turns on the full debug symbols that they require.
Comment 2 David Kilzer (:ddkilzer) 2006-08-14 18:32:11 PDT
(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?
Comment 3 Mark Rowe (bdash) 2006-08-14 19:17:39 PDT
Created attachment 10030 [details]
List of stripped symbols
Comment 4 Mark Rowe (bdash) 2006-08-14 19:18:15 PDT
Created attachment 10031 [details]
List of stripped symbols (unmangled)
Comment 5 Mark Rowe (bdash) 2006-08-14 19:58:55 PDT
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 6 Darin Adler 2006-08-15 07:58:41 PDT
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?
Comment 7 Timothy Hatcher 2006-08-15 08:51:03 PDT
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."
Comment 8 David Kilzer (:ddkilzer) 2006-08-15 09:17:03 PDT
Will this strip API calls that are "unused" in the framework but need to be there for external software that links to the framework?
Comment 9 Darin Adler 2006-08-15 10:56:31 PDT
(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.
Comment 10 Mark Rowe (bdash) 2006-08-15 16:14:23 PDT
Created attachment 10048 [details]
Updated patch

Updated to include changes to Production configuration.
Comment 11 Timothy Hatcher 2006-08-15 16:25:20 PDT
Landed in r15893.
Comment 12 Jon 2006-08-15 16:34:17 PDT
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.
Comment 13 David Kilzer (:ddkilzer) 2006-08-15 19:03:40 PDT
(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.
Comment 14 Mark Rowe (bdash) 2006-08-15 19:07:08 PDT
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.