--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)

[Michael Stahl]

On 22/05/12 15:56, Lubos Lunak wrote:
> On Friday 18 of May 2012, Michael Stahl wrote:
>> On 16/05/12 15:09, Lubos Lunak wrote:

>> (i wonder if -ggdb1 exists and would be sufficient for symbols but don't
>> care enough to try).
> 
>  It does, from gcc manpage: "Level 1 produces minimal information, enough for 
> making backtraces in parts of the program that you don't plan to debug.  This 
> includes descriptions of functions and external variables, but no information 
> about local variables and no line numbers."

hmm.. line numbers are useful though, especially in sw when a method
needs the first 100 lines just to declare all the variables used in the
ugly Pascal-style...

>>>  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?
> 
>  I want code that builds fast. Or rather, code that doesn't take ages to 
> build. LO needs a lot of time for building even without the compiler spending 
> time on optimizing it. But I'm not actually thinking of me, I know I can 
> manually override CXXFLAGS, I'm thinking of people who don't have as powerful 
> build systems and have to wait a long time for builds. I think people are 
> more likely to see big delays rather than many small ones.

i don't think disabling optimization makes the build "fast enough", i
would guess most people figure out that anybody can change a header in
sal any day, and that will take too long to rebuild in any case, and the
only sane way to actually work and not just wait for builds is to keep a
checkout and not rebase it for at least a week.

but i don't care that much about it, and wonder what other developers
think about optimization in --enable-dbgutil.

>> 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.
> 
>  I don't, it's something else introducing it. But that's just a bug somewhere.

weird, just tried out with --enable-debug=sal/ and i get -O0 -ggdb2 in
sal but -O2 and no -g in xml2cmp (as dbgutil and symbols default to off).

>>>>     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);
> 
>   But --enable-debug enables assertions, logging and other stuff, 
> so --enable-debug=sc/ seems to suggest that they will be only enabled in 
> sc/ , while in fact they will be enabled everywhere, and only -g will be 
> enabled in sc/ .

hmm... looks like there's still a bug there, the debuglevel is still a
global variable while it should be tied into the LinkTarget_get_cflags
stuff.

> So it is "selective symbol" and not "selective debug", 
> because it only controls -g and has since Bjoern's first version.

Bjoern's first version disabled compiler optimization but not
OSL_DEBUG_LEVEL, just like the current situation.

> Having this 
> selectivity controlled by --enable-debug only adds to the confusion about 
> what option actually does what.

no, it makes things clearer: if you want to debug Writer ODF import,
then use "--enable-debug=xmloff/ sw/" and you get a build where you can
easily step through with gdb and get more-or-less helpful assertions as
well when things go wrong (or equivalently "make xmloff.clean sw.clean
&& make xmloff sw debug=t").  no need to remember how to set up each of
these things individually.