On Tue, Nov 24, 2020 at 7:38 PM David Blaikie <dblai...@gmail.com> wrote: > > On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek <ja...@redhat.com> wrote: > > > > On Tue, Nov 24, 2020 at 12:04:45PM +0100, Mark Wielaard wrote: > > > Hi, > > > > > > On Tue, 2020-11-24 at 08:50 +0100, Richard Biener wrote: > > > > On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek <ja...@redhat.com> wrote: > > > > > I agree with Richard and I'd lean towards -gdwarf32/-gdwarf64, even > > > > > when DWARF 32 is released in 81 years from now or how many, it would > > > > > use -gdwarf-32. > > > > > > > > Works for me. Let's go with -gdwarf32/64. > > > > > > I don't have a strong opinion, so if that is the consensus, lets go > > > with that. The only open question (which I wanted to avoid by picking > > > -f...) is whether it enables generating debuginfo as is normal when > > > using any -goption, or whether you need another -goption to explicitly > > > turn on debuginfo generation when using -gdwarf32/64? My preference > > > would be that any option starting with -g enables debuginfo generation > > > and no additional -g is needed to keep things consistent. > > > > I think we lost that consistency already, I think -gsplit-dwarf has been > > changed quite recently not to imply -g. > > My understanding was that that change hasn't gone in at this point, in > part because of the issue of changing the semantics of an existing > flag and discussions around whether -g implies debug info. Could you > confirm if this change has been made in GCC? as it may be important to > make a similar change in Clang for consistency. > > Not that Split DWARF would be the first example of -g flags that don't > imply -g. (-ggnu-pubnames, I think, comes to mind) > > > That said, for -gdwarf32/64, I think it is more sensible to enable debug > > info than not to. > > Given my (& I think others on both GCC and Clang from what I gathered > from the previous threads) fairly strong desire to allow selecting > features without enabling debug info - perhaps it'd make sense for > Clang to implement -fdwarf32/64 and then can implement -gdwarf32/64 > for compatibility whenever GCC does (without implementing -gdwarf32/64 > with potentially differing semantics than GCC re: enabling debug info) > > Seems these conversations end up with a bunch of different > perspectives which is compounding the inconsistencies/variety in > flags. > > If there's general agreement that -g* flags should imply -g, maybe we > could carveout the possibility then that -f flags can affect debug > info generation but don't enable it? For users who want to be able to > change build-wide settings while having potentially > per-library/per-file customization. (eg: I want to turn down the debug > info emission on this file (to, say, -gmlt) but I don't want to force > debug info on for this file regardless of build settings)
I don't think that all -g switches have to enable debuginfo generation. Historically the -g flags selecting a debuginfo format did and I guess we need to continue to do that for backward compatibility (-gdwarf, -gstabs, etc.). All other -g flags should not enable debug and some clearly don't, like -gcolumn-info which is even enabled by default. Also -gno-pubnames does not disable debug. >From looking at the source the following options enable debug: -g -gN -gdwarf -gdwarf-N -ggdb -gstabs -gstabs+ -gvms -gxcoff -gxcoff+ all others do not. And yes, the -gsplit-dwarf change went in. Richard. > - Dave
