[PATCH 5/6] configure: allow picking up dwarf version for compilation from command line

[Eric Pouech]

Le 01/10/2021 à 20:14, Jacek Caban a écrit :
> Hi Eric,
>
Hi Jacek,


thanks for the feedback


getting back on it, I think we need to clarify the semantics & goals we 
want to achieve (I wasn't 100% clear myself), as we tackle different 
questions:

- what's wine debug format by default, and how it's going to evolve

- what flexibility is given in configuration for changing it

- what transformation logic is necessary on input parameters


in the following;

- when refer to items (DEBUG, CFLAGS...) related to regular compilation, 
for simplicity, it's implied that the same applies as well to cross 
compilation items (CROSSDEBUG, CROSSCFLAGS)

- I let aside the choice of name between DEBUG vs DEBUGFORMAT


as of today, wine's preferred debug format is "-gdwarf-2 -gstrict-dwarf" 
(for both regular and cross compilation)

note:

- wine's preferred debug format that it is most always different from 
compiler's preferred debug format. gcc claims it's mostly dwarf5 on 
unix, (this will hold true until wine catches up on debug format used by 
default)

- When enabling dwarf4, the exact format still needs from attention (eg: 
strict dwarf or not, Mac OS support to be clarified, see below)

- as of today, the preferred debug format isn't tied to a compiler (it's 
global) (in fact we try if either option -gdwarf-2 and -gstrict-dwarf 
work...)

- CFLAGS defaults to -g -O2 and expects the -g to be transformed into 
wine's preferred format

- this may have to be revisited as:

     - as of today, dwarf-2 support is no longer in gcc default's 
configuration and must be explicitely enabled at configuration time...

     - there are cases when it's not - see for example thread on 
wine-devel on GCC11 with open suse conf where it's not, so this could 
end up as only -gstrict-dwarf -g, which will turn into dwarf5 :-)

     - gcc doc says that macos/darwin defaults to dwarf2. I tested 
homebrew/gcc and Xcode's clang on big sur, they both default to dwarf4, 
but I haven't tested on previous versions (may likely be dwarf2)


what could be done:


DEBUG (when specified)

- used to choose a debug format for compiling wine

- I'd suggest a more drastic approach than what we have today: just 
append DEBUG content as it is to EXTRACFLAGS. this gives total 
flexibility on what we may want to experiment ; note: it will require 
using -gcodeview (not -gpdb nor pdb) in CROSSDEBUG

- this means that no transformation logic is applied on this option ; 
this option should be for internal maintenance and forcing some given 
options

- note that -g will still be present in CFLAGS, but shouldn't harm ; if 
CFLAGS has more -g* option, it may be necessary to erase them all


when DEBUG is not specified

- try to elaborate debug format from CFLAGS

- several debug entries (-g*) can be present in CFLAGS

- support the following transformations (it means removing all -g* 
options from CFLAGS and append to EXTRACFLAGS the result of their 
tranformation)

    -g => wine's preferred debug format. (* see below)

    -gdwarf => wine's preferred debug format.

    -gdwarf-X => kept as is. but do we add strict dwarf or not ? I'd say
    enforce strict dwarf for dwarf2 (as we have it in place), and decide
    later on if we need it elsewhere

    -gpdb => -gcodeview (synonym)

    -g* => (all the other debug options) retained as is


reguarding the transformation of several options, like CFLAGS=-gdwarf-X -g

+ we need to explicit what meaning bears -g

+ in gcc, it can be used either when pushing elements down the chain for 
enabling debug management, and/or to pick up default format when no 
other -g option is specified

so we may have to keep the same logic:

transformation of -g:

- if first -g* option in CFLAGS, then transform it into wine's preferred 
debug format

- if not first, keep as -g


comments welcomed


A+

>> +  AC_SUBST(DEBUGFORMAT)
>
>
> AC_SUBST is not needed here, you don't use it outside configure script
I blindly copied what is done with DEBUG in configure.ac... should we 
get rid of it as well, it's not used in any of .in files ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20211003/3c007628/attachment-0001.htm>