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?
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
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.
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.
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.
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...?
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
Mass re-assign of bugs that aren't on the build team radar, so bugs assigned to email@example.com reflects reality. If there is a bug you really think we need to be looking at, please *email* firstname.lastname@example.org with a bug number and explanation.
Assignee: build → nobody
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
You need to log in before you can comment on or make changes to this bug.