Re: --enable-debug vs --enable-symbols (Re: [Libreoffice-commits] .: 12 commits - config_host.mk.in configure.in filter/source oox/source sal/inc sc/source solenv/gbuild toolkit/source xmlhelp/source)

On 16/05/12 15:09, Lubos Lunak wrote:
> On Tuesday 08 of May 2012, Michael Stahl wrote:

sorry for the late reply

>  Hmm, ok, I don't want to just revert once more, but since it looks to me like 
> you've broken this in several ways, it is possible we don't agree on what 

i'm biased but i bet i broke it in less ways than you and Bjoern did :-P

> these switches are actually supposed to do. As far as I can 
> tell, --enable-symbols enables -g, --enable-debug does --enable-symbols and 
> turns on logging+assertions and disables optimizations, and --enable-dbgutils 
> does --enable-symbols plus whatever extra stuff that is BIC. That's 
> indicentally also what --help says about them. What is your idea about what 
> these options do?

so there are 3 options, and --enable-symbols differs from the other 2 in
that it only adds symbols to the output, it does not enable any
debugging feature, or assertion, it does not disable optimizations, and
it is primarily used not by developers, but by distributors who want to
be able to produce reliable stack traces for _product_ builds, e.g. the
Fedora RPM spec file unconditionally sets --enable-symbols, these
symbols are split out by some RPM magic into libreoffice-debuginfo
package, and then ABRT reports useful stacks to rhbz.

which specific compiler flag is used for --enable-symbol is not all that
relevant as long as it is sufficient to generate stack traces; for
example MSVC uses same flag for --enable-symbol and --enable-debug,
while unxgcc.mk sets -ggdb2 for --enable-symbols and "-ggdb2
-finline-limit=0 -fno-inline -fno-default-inline" for --enable-debug (i
wonder if -ggdb1 exists and would be sufficient for symbols but don't
care enough to try).

the fact that --enable-dbgutil turns on symbols is actually a change
from last year, it used to not do this; i wonder if it was really
intended to change, or whether that was also some consequence of the
debug-level confusion, but i really have no opinion on whether
--enable-dbgutil should imply --enable-symbols or not (but i do consider
it a bug if --enable-dbgutil --disable-symbols doesn't work as intended,
which is currently the case IIRC).

> > commit a50812813de0594ac2aeb064ea4a95d66b8e4e42
> > Author: Michael Stahl <mstahl@redhat.com>
> > Date:   Mon May 7 21:33:01 2012 +0200
> >
> >     gbuild: tie optimization into selective --enable-debug:
> >
> >     Let --enable-debug determine whether optimization should be disabled,
> >     which works also for debug=t due to the setup in gbuild.mk.
> >
> >     Also clean up uses of gb_COMPILEROPTFLAGS: this is now always set to
> >     optimization settings, and gb_COMPILERNOOPTFLAGS used in debug case,
> >     which should not make a difference because the only actual difference
> >     was that on MSVC the debug OPTFLAGS were empty, but -Od is documented
> > as the default for this.
>
>  Now --enable-debug=-sc/ means that sc/ is built without -g and with -O2. In 
> other words, the compiler spends extra time working on code I don't care 
> about at all. There was a reason why OPT flags was empty in --enable-debug 
> build - as soon as I do a developer build, I don't want the compiler to 
> optimize any code, anywhere, unless explicitly told so.

that is surprising; i had thought that developers either want code that
runs fast, or code that is debuggable (i.e. the point of disabling
optimizations is not to confuse the debugger), but you apparently want
slow code that is not debuggable?

it has occasionally annoyed me how horribly slow loading certain large
documents becomes if optimization is disabled.

>  Moreover, such code actually is built also with -g. I'm not sure why, but 
> something now seems to turn on -g for everything, regardless of the selective 
> symbols.

sounds like you also have --enable-symbols on, which works globally, as
the intended target audience doesn't know for which parts stack traces
need to be generated, so it doesn't make sense to sub-divide this.

> > commit c8fa9bd8849f0503b3803465e8ce119581e11e33
> > Author: Michael Stahl <mstahl@redhat.com>
> > Date:   Mon May 7 20:58:44 2012 +0200
> >
> >     dis-entangle --enable-symbols and --enable-debug:
> >
> >     OOo used to use debug level this way:
> >     0 is default for product build
> >     1 for --enable-dbgutil
> >     2 for environment variable debug=t, regardless of dbgutil setting
> >     in LO these have now morphed into:
> >     0 is default for product build
> >     1 for environment variable debug=t
> >     2 for --enable-dbgutil (at some intermediate stage in the past)
> >     1 for --enable-dbgutil (today)
> >
> >     This has caused a lot of confusion and some things were not converted
> >     properly, including a check in LinkTarget.mk.
>
>  This caused confusion even now. How is OSL_DEBUG_LEVEL relevant here at all?

not at all.
but there were several if conditionals in makefiles that used the
equivalent gb_DEBUGLEVEL, one of which you (rightfully) removed in your
original commit.

> >     Developers should use --enable-debug to get useful information,
> >     including full debug info and assertions.
> >
> >     --enable-symbols is not intended for developers, but for people
> >     who need their builds to be able to produce useful stack traces;
> >     --enable-symbols is for example set unconditionally in the Fedora RPM
> >     spec, and for this purpose disabling of inlining is not wanted.
>
>  --enable-symbols should not disable inlining. If it does, it is merely a bug. 
> Why should it, it's for symbols.

of course, that was one of the bugs you introduced :)

> >     It is unlikely that somebody wants symbols for only part of the build,
>
>  Except for those people who wanted the feature of selective debug symbols.
>
> >     and consequently a different mechanism is used to set the corresponding
> >     flags: they are set into global gb_LinkTarget_C{,XX}FLAGS.
> >
> >     So move the selective symbol feature back to --enable-debug.
>
>  That does not make much sense. Even this very sentence says that symbols and 
> debug are again tangled together.

makes sense, because it is in fact not a "selective symbol" but a
"selective debug" feature (and iirc Bjoern had originally implemented it
as such); i just started my fixes with the implementation in
LinkTarget.mk before actually thinking about the bigger picture, so a
lot of my commits refer to "selective symbols".

by the way, one feature that could allow further customization is to
allow for setting CFLAGS etc. per-library, e.g. via environment
variables like Library_sw_CXXFLAGS... just an idea, perhaps nobody wants
this.