Remove FPO and MISC debug data from optimized Win32 builds

RESOLVED WORKSFORME

Status

--
major
RESOLVED WORKSFORME
16 years ago
10 months ago

People

(Reporter: tim, Unassigned)

Tracking

({memory-footprint})

Trunk
mozilla1.6alpha
x86
Windows 2000
memory-footprint

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: CLOSEME NOW!, URL)

(Reporter)

Description

16 years ago
I was reading an old article by Matt Pietrek about shrinking the size of
EXEs and DLLs
(http://www.microsoft.com/msj/defaulttop.asp?page=/msj/archive/s572.htm) and
looking at Mozilla's DLLs with the liposuction utility mentioned in the
article (http://www.wheaty.net/downloads.htm).  You can also list the data
using dumpbin /FPO.

According to the article:
"Another type of debug information that you'll see in Microsoft
compiler-produced executables is Frame Pointer Omission (FPO) information.
FPO is used in conjunction with CodeView or PDB symbols; it assists the
debugger in finding parameters and local variables for functions where the
compiler hasn't generated a standard stack frame using the EBP register. FPO
information can be quite large, so it should be removed (via a linker
switch) before shipping."

"Lastly, in Microsoft compiler-created executables you may see the so-called
miscellaneous debug information. This region seems to always be 0x110 bytes
in length and contains the name of the executable file that the linker
created. If you rename the executable file, debuggers can use miscellaneous
debug information to determine the original name of the file, and from that
calculate the name of the associated PDB file. You get rid of miscellaneous
debug info by doing a nondebug link of the executable file before you ship."

So.. looking at some Mozilla DLLs...  The content/layout DLL has about 200KB
worth of FPO data.  XPCOM.DLL has about 50KB.  Add up the data in all the
other DLLs and you have over 700KB (!) of FPO data in a standard nightly
build, or 450KB in an embed build.  Each DLL also includes MISC debug data,
which is only 272 bytes, but then again Mozilla has lots of DLLs.

I noticed that Phoenix builds do NOT include FPO data or MISC data.  Phoenix
builds are static builds, but even DLLs built separately such as XPCOM.DLL
don't include FPO debug info in Phoenix.

Is there any good reason why this data needs to be in builds for end-users?  Is
it used by Talkback?  Can whatever linker switches the static build / Phoenix is
using to leave out this data be used with Mozilla?

Updated

16 years ago
Keywords: footprint
The win32 release builds are actually MOZ_PROFILE builds so that talkback
contains sufficient debug info.  The debug symbols are stripped out prior to
being shipped though.  Afaik, the phoenix builds are regular optimized builds so
they would not contain any debug information at all.
Over to leaf.
Assignee: seawood → leaf

Comment 2

16 years ago
I wonder if there's some utility that would strip the FPO data out, or how hard
it would be to create such a utility.

Comment 3

16 years ago
stuart wrote this in an email on this subject:

> Assuming this is similar to -fomit-frame-pointer, which is required at least
on > linux for xptcall to work, I doubt it would actually run.

Comment 4

16 years ago
This isn't talking about removing the optimization or changing any of the object
code that is generated. The compiler generates extra debug info so that
debuggers and such can figure out the parameters for functions when the frame
pointer is omitted. The information that would be removed, would only have
impact to a debugger, or possibly Talkback. I don't know enough about Talkback
to know if the client piece of Talkback uses this information, or if only the
server side needs it. I would think only the server side, but that's just a
guess on my part.
(Reporter)

Comment 5

16 years ago
Right.  Mozilla compiles with the /O1 option which implies /Oy, frame pointer 
omission.  However, when debugging is enabled, /Oy adds FPO entries to help 
debuggers with functions that omit frame pointers.  So we need to either change 
the build process to not include the data (as Phoenix is currently doing) or 
strip the data out.  The question is if/how the talkback client relies on it, 
and if it's worth doing.. but I don't know much about talkback.  I guess we'd 
have to crash in a function with FPO, and see how talkback data in builds with 
and without FPO debug data differ.

I did find a utility that strips the FPO data (unfortunately you have to 
register):
http://developer.novell.com/ndk/doc/dllcomp/dll__enu/data/hcnm4srp.html
http://developer.novell.com/ndk/dllcomp.htm

The compressed savings are about 150KB.
I don't suppose cygwin strip can remove this...?

Comment 7

16 years ago
One question: Does Pheonix generate Talkback reports? If it does, and they are
detailed enough, then the build process just needs to be changed.
no, phoenix is without TB

Updated

16 years ago
Target Milestone: --- → mozilla1.4beta

Updated

16 years ago
Target Milestone: mozilla1.4beta → mozilla1.6alpha

Updated

14 years ago
Assignee: leaf → cmp
Product: Browser → Seamonkey

Comment 9

13 years ago
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
Mass re-assign of bugs that aren't on the build team radar, so bugs assigned to build@mozilla-org.bugs reflects reality.

If there is a bug you really think we need to be looking at, please *email* build@mozilla.org with a bug number and explanation.
Assignee: build → nobody

Updated

10 years ago
Component: Build Config → Build Config
Product: SeaMonkey → Core
QA Contact: granrosebugs → build-config
Whiteboard: CLOSEME NOW!
This does not appear to be a problem any more building with Visual C++ 2005.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME

Updated

10 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.