CMake binary sizes Release vs RelWitHDebInfo after strip

[jimc]

Hey -

I’m stretching at the end of my knowledge here.

When i do a plugin build using RelWithDebInfo and strip it my binary is 64Mb instead of about 20Mb.

Any ideas why? I’m deep into linker and compiler options and it’s apparently a hard queston.

What’s the extra info? My TEXT __const section looks pretty massive

(What I’m trying to do is save the symbols using dsymutil so we can debug crash dumps later, and its’ got a lot more complicated that I’d have liked!)

cheers!

[reuk]

Sounds a bit similar to this issue:

Why are CMake executables so much bigger?

Looks like the CMake build enables LTO, the Projucer build doesn’t. The Projucer build enables dead code stripping, the CMake build doesn’t. If I avoid linking the lto_flags target, and set the XCODE_ATTRIBUTE_DEAD_CODE_STRIPPING YES property on the Projucer target, the size of the CMake build drops considerably. I haven’t tested in MSVC, but I see that OptimizeReferences is set in the link settings in the vcxproj, which I think functions similarly to dead_strip on macOS. I’m not sure if there’…

In short, disabling link-time optimisation and enabling dead-code stripping can yield smaller binaries.

my binary is 64Mb instead of about 20Mb.

Where does the second number come from? Is that from a plain release build?

If you’re using the juce_recommended_* targets to supply compiler flags, be aware that some options are only enabled in Release mode, i.e. -flto and -O3 are only passed for Release, but not RelWithDebInfo. I recommend building with --verbose and checking over the commandlines that are generated for RelWithDebInfo builds to check that you’re using the expected optimisation level and other settings.

[jimc]

Yeah, the smaller number is the normal Release build. I’ve set -O3 for RelWithDebInfo. Slightly more confused about the lto settings - looking into it.

Ideally I think I’m going to come at it from the other end by using Release and adding the debug info to it with -g. But struggling to make it make all the right output for dsymutil:

dsymutil /Users/jim/Code/multiband/cmake.build/MultibandX6_artefacts/Release/VST3/Multiband\ X6.vst3/Contents/MacOS/Multiband\ X6 -o ~/Symbols/MultibandX6_VST3_1.0.33.dSYM
warning: (x86_64) /tmp/lto.o unable to open object file: No such file or directory
warning: (arm64) /tmp/lto.o unable to open object file: No such file or directory

[jimc]

Ok, so to get symbols available for dsymutil someone worked out that the solution is: -Wl,-object_path_lto,lto.o

They said:

1. on macOS, the full debug info is never stored in the executable. It is either left in the object files, and the executable just keeps a record of the paths to the object files, or it is put into a “dSYM bundle”.
2. when compiling and linking in a single step with the clang/clang++ drivers and the -g flag, i.e.
3. clang -o app -g main.cpp Matrix.cpp Vector.cpp cholesky.cpp …
4. the driver automatically calls dsymutil at the end of the process to create this dSYM bundle. (this can be seen by adding -v to tell the driver to output all commands it issues.)
5. when compiling and linking in separate steps, which is usually the case with Make- or Automake- based build systems, the driver does not call dsymutil, so the debug info is left in the object files.
6. When compiling and linking in a single step with -flto, the driver calls the linker with the -object_path_lto flag and a path in $TMPDIR, eg. -object_path_lto /var/folders/lr/r6n2057j0dzd4gdb614fp0740000gp/T/cc-ac0bf8.o.
7. when compiling and linking in separate steps, the driver does not add this option to the linker call.
8. man ld reveals that if object_path_lto is not used, the linker deletes the temporary file used for link time optimization after the linking step is finished.
   The last point means that the final executable keeps a reference to this deleted temporary file (I guess /tmp/lto.o is hardcoded in ld64’s source code, I did not check that). So when the executable is loaded in GDB, the debugger tries to load the debugging symbols from the now deleted temporary file.

Adding -Wl,object_path_lto,lto.o to the linking command (in a Makefile for example) leaves the object file used for link time optimization (here lto.o) in the build directory, which allows to debug the executable. It also allows calling dsymutil manually to create the dSYM bundle.

See Enable macOS build by phil-blain · Pull Request #23 · conda-forge/gdb-feedstock · GitHub

and documentation of -object_path_lto here : man page ld64 section 1

[jimc]

Well, now I’m onto: [GUIDE] Symbolicating Release Builds - #9 by KoenTanghe

warning: could not find referenced DIE

This error which no-one solved in the previous thread on the topic!

It’s finds a bunch of stuff

Found valid debug map entry: __ZN4juce7ColoursL8honeydewE.16180	0x0000000004cff97c => 0x0000000000cceaac
Keeping variable DIE:
0x0120a8e5:         DW_TAG_variable [577]
                      DW_AT_name [DW_FORM_strp]	( .debug_str[0x00028675] = "honeydew")
                      DW_AT_type [DW_FORM_ref_addr]	(0x000000000015e621 "const Colour")
                      DW_AT_decl_file [DW_FORM_data1]	("/Users/jim/Code/multiband/swag/juce/modules/juce_graphics/colour/juce_Colours.h")
                      DW_AT_decl_line [DW_FORM_data1]	(96)
                      DW_AT_location [DW_FORM_exprloc]	(DW_OP_addr 0x4cff97c)
                      DW_AT_linkage_name [DW_FORM_strp]	( .debug_str[0x0002867e] = "_ZN4juce7ColoursL8honeydewE")
Found valid debug map entry: __ZN4juce7ColoursL7hotpinkE.16181	0x0000000004cff980 => 0x0000000000cceab0

But, oddly also from the JUCE libary, it fails to find a load of other things

0x001ef4e3:       DW_TAG_inlined_subroutine [381] *
                    DW_AT_abstract_origin [DW_FORM_ref4]	(cu + 0x170cda => {0x00170cda})
                    DW_AT_ranges [DW_FORM_sec_offset]	(0x001606f0
                       [0x000000000012d6f4, 0x000000000012d710)
                       [0x000000000012d814, 0x000000000012d878))
                    DW_AT_call_file [DW_FORM_data1]	("/Users/jim/Code/multiband/swag/juce/modules/juce_gui_basics/accessibility/interfaces/juce_AccessibilityTableInterface.h")
                    DW_AT_call_line [DW_FORM_data1]	(199)
                    DW_AT_call_column [DW_FORM_data1]	(0x1f)
warning: could not find referenced DIE
note: while processing /Users/jim/Code/multiband/cmake.build/lto_vst3.o
note:     in DIE:

0x001ef4fa:       DW_TAG_inlined_subroutine [380] *
                    DW_AT_abstract_origin [DW_FORM_ref4]	(cu + 0x170caa => {0x00170caa})
                    DW_AT_ranges [DW_FORM_sec_offset]	(0x00160720
                       [0x000000000012d6f4, 0x000000000012d710)
                       [0x000000000012d814, 0x000000000012d878))
                    DW_AT_call_file [DW_FORM_data1]	("/Users/jim/Code/multiband/swag/juce/modules/juce_audio_processors/format_types/VST3_SDK/pluginterfaces/vst/ivsttestplugprovider.h")
                    DW_AT_call_line [DW_FORM_data2]	(2910)
                    DW_AT_call_column [DW_FORM_data1]	(0x01)
warning: could not find referenced DIE
note: while processing /Users/jim/Code/multiband/cmake.build/lto_vst3.o
note:     in DIE:

Ah - I think the commonality here is that it can’t find the things that have been inlined