[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Solaris (#479)

Tobias Pape Das.Linux at gmx.de
Mon Apr 6 06:12:19 UTC 2020

> On 06.04.2020, at 08:00, K K Subbu <kksubbu.ml at gmail.com> wrote:
> On 06/04/20 10:24 AM, Tobias Pape wrote:
>>> Production builds should be using -O and not "-g -Ox" option.
>> Why? Really. It rather depends on the compiler, no? With gcc and
>> clang, -g+-O is actually a good idea, especially if you use
>> "external" debug symbols like dwarf directories...
> Yes, debug options are compiler dependent to balance between speed optimization and ease of debugging. For instance, gcc recommends:
> ----https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> If you are not using some other optimization option, consider using -Og (see Optimize Options) with -g. With no -O option at all, some compiler passes that collect information useful for debugging do not run at all, so that -Og may result in a better debugging experience.
> ----
> I would expect alpha and possibly beta to use debug but RC or release versions to optimize aggressively for speed. Debug builds may be instrumented for bounds check, initialized alloc, leak checks, overflow checks etc. These could slow down squeak vm.

That _really_ depends. And actually, why should writing debug info into the binary slow things down?
It at most increases the size of the binary. Optimization on GCC/clang is only handled via the -O?? flag.

In fact, on OSX a common pattern is (was?) to compile with debug symbols but not put them in the binary but a directory besides it.
That way you can distribute the Binary w/o the debug symbols but have them handy in case you need to debug the release binary on your end.

TL;DR: there is really no need to remove '-g' on gcc/clang, even in release builds.

Best regards

More information about the Vm-dev mailing list