Re: Future debug options: -f* or -g*?

[David Blaikie via Gcc]

On Thu, Jul 9, 2020 at 12:03 PM Fangrui Song  wrote:
>
> Both GCC and Clang have implemented many debugging options under -f and
> -g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
>
> A non-complete list of GCC supported debug options is documented here at
> https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
>
> I think there options belong to 3 categories:
>
> (a) -f* & doesn't imply -g2: -fdebug-types-section 
> -feliminate-unused-debug-types,
> -fdebug-default-version=5 (this exists in clang purely because -gdwarf-5 
> implies -g2 & there is need to not imply -g2)
> (b) -g* & implies -g2: -gsplit-dwarf (I want to move this one to (c) 
> http://lists.llvm.org/pipermail/cfe-dev/2020-July/066202.html )
>  -gdwarf-5, -ggdb, -gstabs
> (c) -g* but does not imply -g2: -ggnu-pubnames, -gcolumn-info, 
> -gstrict-dwarf, -gz, ...
>  the list appears to be much longer than (b)

Not sure that's the case - it seemed about even last I counted. Here's
my count (I didn't test all the -g flags, some might actually be (b)
when I classified them as (c) - which is sort of my
point/preference/issue here: a -f flag I know won't enable debug info,
a -g flag... I'm not entirely sure), going from the Debugging-Options
document:

a)
-fno-eliminate-unused-debug-symbols
-femit-class-debug-always
-fno-merge-debug-strings
-fdebug-prefix-map=old=new
-fvar-tracking
-fvar-tracking-assignments
-fdebug-types-section
-femit-struct-debug-baseonly
-femit-struct-debug-reduced
-femit-struct-debug-detailed
-fno-dwarf2-cfi-asm
-fno-eliminate-unused-debug-types

b)
-g
-ggdb
-gdwarf-N
-gstabs/-gstabs+
-gxcoff/-gxcoff+
-gvms
-g{,gdb,stabs,xcoff,vms}N
-gsplit-dwarf

c)
-gdescribe-dies
-gpubnames
-ggnu-pubnames
-g[no-]record-gcc-switches
-g[no-]strict-dwarf
-g[no-]as-loc-support
-g[no-]as-locview-support
-g[no-]column-info
-g[no-]statement-frontiers
-g[no-]variable-location-views
-g[no-]internal-reset-location-views
-g[no-]inline-points
-gz

And the counts vary a bit depending on how much you collapse variants
(especially in (b), with the format x N combinatorial situation).

The other dimension that'd be harder to get data on, would be how
often each of these flags are used - most of the finer grained
location/variable stuff I doubt people use all that often? The ones
I've used regularly are -gdwarf-N, -ggnu-pubnames,
-fdebug-types-section, that might be about it? So in my case I guess
it's a somewhat even split, but I've learnt that -ggnu-pubnames "isn't
like -g"/doesn't enable production of debug info.

> ( (b) isn't very good to its non-orthogonality. The interaction with -g0 -g1
>and -g3 can be non-obvious sometimes.)
>
> Cary Coutant kindly shared with me his understanding about debug
> options (attached at the end). Many established options can't probably
> be fixed now. Some are still fixable (-gsplit-dwarf).
>
> This post is mainly about future debug options. Shall we figure out a
> convention for future debug options?
>
> Personally I'd prefer (c) but I won't object to (a).
> I'd avoid (b).

While I have some apprehension about -gsplit-dwarf moving out of (b),
in general (even in -gsplit-dwarf) the orthogonality of "how to emit
DWARF" versus "whether to emit DWARF" is certainly beneficial, and I'm
on board with a general preference/move away from (b) maybe entirely
except for the singular "-g" if we were designing things from scratch.
(that way anyone can set a build policy of "this is the sort of debug
info I need across the project" and "these are the files I need that
debug info for" (by adding -g on a per-file basis), yeah, sometimes
you might want "But on this file I want this kind of debug info
(current -gmlt, for instance)" but you can get that by composition
with -g +  flag, whereas it's
harder or not possible to do the reverse)

> > In retrospect, I regret not naming the option -fsplit-dwarf, which
> > clearly would not have implied -g, and would have fit in with a few
> > other dwarf-related -f options. (I don't know whether Richard's
> > objection to it is because there is already -gsplit-dwarf, or if he
> > would have objected to it as an alternative-universe spelling.)
> >
> > At the time, I thought it was fairly common for all/most -g options
> > (except -g0) to imply -g. Perhaps that wasn't true then or is no
> > longer true now. If the rest of the community is OK with changing
> > -gsplit-dwarf to not imply -g, and no one has said it would cause them
> > any hardship, I'm OK with your proposed change.
> >
> > I did design it so that you could get the equivalent by simply writing
> > "-gsplit-dwarf -g0" at the front of the compiler options (e.g., via an
> > environment variable), so that a subsequent -g would not only turn on
> > debug but would also enable split-dwarf. We used that fairly regularly
> > at Google.
> >
> > Regarding how the build system can discover whether or not split dwarf
> > is in effect, without parsing all the options present

Re: Future debug options: -f* or -g*?

[David Blaikie via Gcc]

On Fri, Jul 10, 2020 at 12:09 PM Nathan Sidwell  wrote:
>
> On 7/9/20 3:28 PM, Fangrui Song via Gcc wrote:
> > Fix email addresses:)
> >
>
> IMHO the -f ones are misnamed.
> -fFOO -> affect generated code (non-target-specific) or language feature
> -gFOO -> affect debug info
> -mFOO -> machine-specific option
>
> the -fdump options are misnamed btw, I remember Jeff Law pointed that out 
> after
> Mark Mitchell added the first one.  I'm not sure why we didn't rename it right
> then.  I'll bet there are other -foptions that don;t match my comfortable 
> world
> view :)

Appreciate the perspective, for sure!

It sounds like some folks who've worked on this a fair bit (at least
myself, Eric Christopher, and Cary Coutant) have had a different
perspective for quite a while - that -g flags generally turn on debug
info emission (& customize it in some way, potentially) and -f flags
modify the emission but don't enable it.

Specifically this conversation arose around changing the semantics of
-gsplit-dwarf, which currently enables debug info emission and
customizes the nature of that emission. There's a desire to separate
these semantics.

I have a few issues with this that I'd like to avoid:

1) changing the semantics of an existing flag (I think it's best to
introduce a new one, perhaps deprecate the old one), especially across
two compilers, issues around version compatibility, etc seem less than
ideal
2) especially given the existing semantics of the flag it seems like
it'd add to the confusion to make -gsplit-dwarf no longer imply -g2,
whereas adding -fsplit-dwarf would be less ambiguous/more clear that
this is not going to turn on debug info emission

Going forward for new flags, I still feel like (given the current
proliferation of -g flags that do enable debug info emission and tweak
it) the ambiguity of -g flags is problematic from a usability
perspective, but I'd be less opposed to new flags using -g than I am
to changing the semantics of an existing -g flag.

If GCC is outright "hard no" on -fsplit-dwarf and (sounds like) has
already changed -gsplit-dwarf semantics, Clang will essentially have
to follow to avoid greater confusion, but I'd like to avoid that if
possible.

Thoughts? Are there other ways we could reduce the ambiguity between
"enables debug info" and "tweaks debug info emission, if enabled"?

- Dave

>
> nathan
>
> > On 2020-07-09, Fangrui Song wrote:
> >> Both GCC and Clang have implemented many debugging options under -f and
> >> -g. Whether options go to -f or -g appears to be pretty arbitrary 
> >> decisions.
> >>
> >> A non-complete list of GCC supported debug options is documented here at
> >> https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> >>
> >> I think there options belong to 3 categories:
> >>
> >> (a) -f* & doesn't imply -g2: -fdebug-types-section
> >> -feliminate-unused-debug-types,
> >>   -fdebug-default-version=5 (this exists in clang purely because -gdwarf-5
> >> implies -g2 & there is need to not imply -g2)
> >> (b) -g* & implies -g2: -gsplit-dwarf (I want to move this one to (c)
> >> http://lists.llvm.org/pipermail/cfe-dev/2020-July/066202.html )
> >>-gdwarf-5, -ggdb, -gstabs
> >> (c) -g* but does not imply -g2: -ggnu-pubnames, -gcolumn-info, 
> >> -gstrict-dwarf,
> >> -gz, ...
> >>the list appears to be much longer than (b)
> >>
> >> ( (b) isn't very good to its non-orthogonality. The interaction with -g0 
> >> -g1
> >>  and -g3 can be non-obvious sometimes.)
> >>
> >> Cary Coutant kindly shared with me his understanding about debug
> >> options (attached at the end). Many established options can't probably
> >> be fixed now. Some are still fixable (-gsplit-dwarf).
> >>
> >> This post is mainly about future debug options. Shall we figure out a
> >> convention for future debug options?
> >>
> >> Personally I'd prefer (c) but I won't object to (a).
> >> I'd avoid (b).
> >>
> >>> In retrospect, I regret not naming the option -fsplit-dwarf, which
> >>> clearly would not have implied -g, and would have fit in with a few
> >>> other dwarf-related -f options. (I don't know whether Richard's
> >>> objection to it is because there is already -gsplit-dwarf, or if he
> >>> would have objected to it as an alternative-universe spelling.)
> >>>
> >>> At the time, I thought it was fairly common for all/most -g options
> >>> (except -g0) to imply -g. Perhaps that wasn't true then or is no
> >>> longer true now. If the rest of the community is OK with changing
> >>> -gsplit-dwarf to not imply -g, and no one has said it would cause them
> >>> any hardship, I'm OK with your proposed change.
> >>>
> >>> I did design it so that you could get the equivalent by simply writing
> >>> "-gsplit-dwarf -g0" at the front of the compiler options (e.g., via an
> >>> environment variable), so that a subsequent -g would not only turn on
> >>> debug but would also enable split-dwarf. We used that fairly regularly
> >>> at Google.
> >>>
> >>> Regarding how the 

Re: Coding style for C++ constructs going forward

[David Blaikie via Gcc]

On Tue, Aug 11, 2020 at 7:49 PM Liu Hao via Gdb  wrote:
>
> 在 2020/8/11 下午9:55, Nathan Sidwell 写道:
> >
> > I agree, it's the way I use auto.  I particularly like the
> >auto *foo = expr;
> > idiom, when you're getting a pointer, but the type of the pointee is clear. 
> >  It informs how you use 'foo'.
> >
> >
>
> Personally I dislike this syntax. Pointers are objects, and `auto foo = 
> expr;` should suffice. What if the type of `expr` is
> `unique_ptr` or `optional`? The ptr-operator just can't exist there. So 
> why the differentiation?
>
> `auto& foo = ...` and `const auto& foo = ...` are necessary to indicate that 
> the entity being declared is a reference (and
> is not an object), while `auto*` doesn't make much sense, as I discourage 
> plain pointers in my projects.

Then use of `auto*` would make it easier for you to spot use of plain
pointers in your projects & scrutinize them further?

>
>
>
> --
> Best regards,
> LH_Mouse
>

Re: Future debug options: -f* or -g*?

[David Blaikie via Gcc]

Hey Mark - saw a little of/bits about your presentation at LPC 2020 GNU
Tools Track (& your thread on on the gdb list about debug_names). Wondering
if you (or anyone else you know who's contributing to debug info in GCC)
have some thoughts on this flag naming issue. It'd be great to get some
alignment between GCC and Clang here, so as we both add new flags going
forward, at least they're at least categorically consistent for users, even
if we aren't necessarily implementing the exact same flags/flag names
(though in the -gsplit-dwarf case, it'd be good for any new semantics/name
to match exactly).

On Wed, Jul 29, 2020 at 9:46 AM David Blaikie  wrote:

> On Fri, Jul 10, 2020 at 12:09 PM Nathan Sidwell  wrote:
> >
> > On 7/9/20 3:28 PM, Fangrui Song via Gcc wrote:
> > > Fix email addresses:)
> > >
> >
> > IMHO the -f ones are misnamed.
> > -fFOO -> affect generated code (non-target-specific) or language feature
> > -gFOO -> affect debug info
> > -mFOO -> machine-specific option
> >
> > the -fdump options are misnamed btw, I remember Jeff Law pointed that
> out after
> > Mark Mitchell added the first one.  I'm not sure why we didn't rename it
> right
> > then.  I'll bet there are other -foptions that don;t match my
> comfortable world
> > view :)
>
> Appreciate the perspective, for sure!
>
> It sounds like some folks who've worked on this a fair bit (at least
> myself, Eric Christopher, and Cary Coutant) have had a different
> perspective for quite a while - that -g flags generally turn on debug
> info emission (& customize it in some way, potentially) and -f flags
> modify the emission but don't enable it.
>
> Specifically this conversation arose around changing the semantics of
> -gsplit-dwarf, which currently enables debug info emission and
> customizes the nature of that emission. There's a desire to separate
> these semantics.
>
> I have a few issues with this that I'd like to avoid:
>
> 1) changing the semantics of an existing flag (I think it's best to
> introduce a new one, perhaps deprecate the old one), especially across
> two compilers, issues around version compatibility, etc seem less than
> ideal
> 2) especially given the existing semantics of the flag it seems like
> it'd add to the confusion to make -gsplit-dwarf no longer imply -g2,
> whereas adding -fsplit-dwarf would be less ambiguous/more clear that
> this is not going to turn on debug info emission
>
> Going forward for new flags, I still feel like (given the current
> proliferation of -g flags that do enable debug info emission and tweak
> it) the ambiguity of -g flags is problematic from a usability
> perspective, but I'd be less opposed to new flags using -g than I am
> to changing the semantics of an existing -g flag.
>
> If GCC is outright "hard no" on -fsplit-dwarf and (sounds like) has
> already changed -gsplit-dwarf semantics, Clang will essentially have
> to follow to avoid greater confusion, but I'd like to avoid that if
> possible.
>
> Thoughts? Are there other ways we could reduce the ambiguity between
> "enables debug info" and "tweaks debug info emission, if enabled"?
>
> - Dave
>
> >
> > nathan
> >
> > > On 2020-07-09, Fangrui Song wrote:
> > >> Both GCC and Clang have implemented many debugging options under -f
> and
> > >> -g. Whether options go to -f or -g appears to be pretty arbitrary
> decisions.
> > >>
> > >> A non-complete list of GCC supported debug options is documented here
> at
> > >> https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
> > >>
> > >> I think there options belong to 3 categories:
> > >>
> > >> (a) -f* & doesn't imply -g2: -fdebug-types-section
> > >> -feliminate-unused-debug-types,
> > >>   -fdebug-default-version=5 (this exists in clang purely because
> -gdwarf-5
> > >> implies -g2 & there is need to not imply -g2)
> > >> (b) -g* & implies -g2: -gsplit-dwarf (I want to move this one to (c)
> > >> http://lists.llvm.org/pipermail/cfe-dev/2020-July/066202.html )
> > >>-gdwarf-5, -ggdb, -gstabs
> > >> (c) -g* but does not imply -g2: -ggnu-pubnames, -gcolumn-info,
> -gstrict-dwarf,
> > >> -gz, ...
> > >>the list appears to be much longer than (b)
> > >>
> > >> ( (b) isn't very good to its non-orthogonality. The interaction with
> -g0 -g1
> > >>  and -g3 can be non-obvious sometimes.)
> > >>
> > >> Cary Coutant kindly shared with me his understanding about debug
> > >> options (attached at the end). Many established options can't probably
> > >> be fixed now. Some are still fixable (-gsplit-dwarf).
> > >>
> > >> This post is mainly about future debug options. Shall we figure out a
> > >> convention for future debug options?
> > >>
> > >> Personally I'd prefer (c) but I won't object to (a).
> > >> I'd avoid (b).
> > >>
> > >>> In retrospect, I regret not naming the option -fsplit-dwarf, which
> > >>> clearly would not have implied -g, and would have fit in with a few
> > >>> other dwarf-related -f options. (I don't know whether Richard's
> > >>> objection to it

Re: Future debug options: -f* or -g*?

[David Blaikie via Gcc]

On Wed, Sep 2, 2020 at 4:12 AM Mark Wielaard  wrote:

> Hi David,
>
> On Mon, 2020-08-31 at 20:10 -0700, David Blaikie wrote:
> > Hey Mark - saw a little of/bits about your presentation at LPC 2020 GNU
> > Tools Track (& your thread on on the gdb list about debug_names).
> Wondering
> > if you (or anyone else you know who's contributing to debug info in GCC)
> > have some thoughts on this flag naming issue. It'd be great to get some
> > alignment between GCC and Clang here, so as we both add new flags going
> > forward, at least they're at least categorically consistent for users,
> even
> > if we aren't necessarily implementing the exact same flags/flag names
> > (though in the -gsplit-dwarf case, it'd be good for any new
> semantics/name
> > to match exactly).
>
> To be honest I don't have any deep insights here. Sadly it is just a
> bit of a mess.


Happen to know any other interested parties (other GCC DWARF contributors
who might have an opinion on flag naming) who might want to weigh in/help
us converge here?


> Not helped by the fact that some debugging formats, like
> DWARF have a number in their name (dwarf2) that might not reflect
> actually reflext the version of that format (except for it being not-
> dwarf1). That is why I was suggesting to use -fdwarf(32|64) instead of
> -gdwarf(32|64) to use for 32 bits vs 64 bits offsets in dwarf(2|3|4|5),
> because there are already too many -gdwarf[number] options.
>
> The idea of having any of the -fs not imply -g and having
> any of the -gs imply -g seems a good one.
>

Cool cool.


> But in general I think these suboptions are all a bit nonsense though.
> They are great for tinkering and playing with corner cases of the
> debugging format. But I don't think we are helping real developers with
> them. To make any of them useful they should be in one of the standard
> options that people actually use. Nobody has time (or the specialized
> knowledge) to really care about all these suboptions. Once people feel
> they need to use any of these suboptions we already lost or the user
> has such specialized knowledge that they will know about specific
> changes in these options or between compilers.
>

Perhaps - I think there are different use cases. A big one in LLVM we call
-fstandalone-debug: Are you building everything with debug info, or only
one or two files/can the compiler assume other files will be built with
debug info. (this affects basically the same things as
-femit-class-debug-always). Split DWARF for users with distributed build
systems. Several options can weight object size compared to linked
executable size - such as using base address selection entries in range and
location lists (reducing relocations). Obviously I'm biased here - I live
in this stuff & have users/use cases that are... not the norm.


> So just like we have -Wall or -Wextra has groups of warning options
> people are likely to use and we have -O1, -O2 and -O3 (I personally
> believe -flto should just be in -O3 instead of being a separate
> option),


I imagine quite a few users build with optimization for particular CPUs -
though, again, partly my bias of working on a homogenous/controlled
environment in data centers, rather than trying to build a binary to send
to random users in the world. But I'd guess games and things that want to
eek out performance probably want to use modern CPU features if available.


> we should simply focus on making -g1, -g2 and -g3 have good
> defaults. Where -g1 is the minimum needed to do some
> profiling/tracing/debugging without needing to map all addresses back
> to source completely but can leave out full type trees for example, -g2
> is the default for being able to do a useful interactive debugging
> session and -g3 adds some (expensive) extras like .debug_macros and
> maybe .debug_names, etc.
>

Maybe. I'd guess a fair few users (especially in their continuous
integration systems, etc) might have some different tradeoffs in terms of
compile/link time and debugging/debugger startup time (indexes are a
particularly potent example of this - pay some link time for some debugger
startup improvement - but if I don't use a debugger very often, I may not
want to pay that link time cost all the time).


> With respect to -gsplit-dwarf I think it was (in hindsight) a mistake
> to put things in a separate (.dwo) file. It is a bit confusing to users
> and complicates build systems immensely. I am hoping to implement
> -gsplit-dwarf=single using SHF_EXCLUDED for gcc and then make that the
> default.
>

Yeah, we've got support for that model in Clang - but to be honest, one of
the major motivations for implementing Split DWARF was Google's internal
use (big distributed build system) & the split mode isn't a mistake in this
context - not having to ship all the DWARF bytes to the machine doing the
link is a significant savings. (even if we ship all those bytes to another
machine to make a dwp) and smaller files to pull down when a user wants to
debug fr

Re: DWARF64 gcc/clang flag discussion

[David Blaikie via Gcc]

On Mon, Nov 23, 2020 at 12:32 AM Richard Biener
 wrote:
>
> On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org  wrote:
> >
> > On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote:
> > > On llvm side of compiler world there has been work done by Igor Kudrin to 
> > > enable DWARF64.
> > > I am trying to add a flag to Clang to enable DWARF64 generation. 
> > > https://reviews.llvm.org/D90507
> > > In review David Blaikie pointed out that there has been a discussion on 
> > > what to call this flag:
> > > https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf
> > > https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt
> > > https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html
> > >
> > > Reading through that it doesn't look like there is a consensus on what it 
> > > should be.
> > >
> > > From discussion there is seems to be mixed opinion if it should be
> > > -f or -g. Primarily centered around if -g prefix implies
> > > turning on generation of debug information.
> > >
> > > Now that LLVM can actually generate DWARF64 for ELF, can we come to 
> > > consensus on the name?
> >
> > I don't believe any firm consensus was reached on naming yet.  But I
> > would pick -fdwarf32/-fdwarf64.
>
> I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will
> never reach version 32 or 64?
> maybe -g32 / -g64 similar to -m32/-m64 are good enough?)

Any sense of a good way to break the tie/uncertainty?

Alternatively: If Clang picks something here (likely from within this
range of candidates - though given I've got a fair bit of say on the
Clang side, and if left to me, I'd probably lean heavily on the
-fdwarf32/64 side), is it likely that choice will tend to be adopted
by GCC? I'd rather not get out of sync, but I expect a bit hard to get
a conclusion on the GCC side without patches in progress, etc. Got a
sense of who are the people who would likely be deciders/patch
approvers for such a naming choice on the GCC side?

- Dave

Re: DWARF64 gcc/clang flag discussion

[David Blaikie via Gcc]

On Mon, Nov 23, 2020 at 6:59 PM Jeff Law  wrote:
>
>
>
> On 11/23/20 7:38 PM, David Blaikie via Gcc wrote:
> > On Mon, Nov 23, 2020 at 12:32 AM Richard Biener
> >  wrote:
> >> On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org  wrote:
> >>> On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote:
> >>>> On llvm side of compiler world there has been work done by Igor Kudrin 
> >>>> to enable DWARF64.
> >>>> I am trying to add a flag to Clang to enable DWARF64 generation. 
> >>>> https://reviews.llvm.org/D90507
> >>>> In review David Blaikie pointed out that there has been a discussion on 
> >>>> what to call this flag:
> >>>> https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf
> >>>> https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt
> >>>> https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html
> >>>>
> >>>> Reading through that it doesn't look like there is a consensus on what 
> >>>> it should be.
> >>>>
> >>>> From discussion there is seems to be mixed opinion if it should be
> >>>> -f or -g. Primarily centered around if -g prefix implies
> >>>> turning on generation of debug information.
> >>>>
> >>>> Now that LLVM can actually generate DWARF64 for ELF, can we come to 
> >>>> consensus on the name?
> >>> I don't believe any firm consensus was reached on naming yet.  But I
> >>> would pick -fdwarf32/-fdwarf64.
> >> I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will
> >> never reach version 32 or 64?
> >> maybe -g32 / -g64 similar to -m32/-m64 are good enough?)
> > Any sense of a good way to break the tie/uncertainty?
> >
> > Alternatively: If Clang picks something here (likely from within this
> > range of candidates - though given I've got a fair bit of say on the
> > Clang side, and if left to me, I'd probably lean heavily on the
> > -fdwarf32/64 side), is it likely that choice will tend to be adopted
> > by GCC? I'd rather not get out of sync, but I expect a bit hard to get
> > a conclusion on the GCC side without patches in progress, etc. Got a
> > sense of who are the people who would likely be deciders/patch
> > approvers for such a naming choice on the GCC side?
> Historically debugging options belong under -g on the GCC side and
> options that twiddle code generation are under -f.  So -gdwarf32
> /-gdwarf64 or -g32/-g64 seem like the right options for GCC.

Did you happen to catch the other thread linked above (
https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html ) where
there are a fair few examples of both -g and -f flags affecting debug
info (& significant contributors, like Cary, who seem to share some of
the "-f flags seem reasonable for
debug-info-affecting-but-not-activating flags" perspective), combined
with the ambiguity of "does this -g* option enable debug info, or only
tweak how debug info would be emitted if debug info is otherwise
requested"?

(the other thread is more difficult owing to -gsplit-dwarf already
having existing semantics - but I'd say this thread is also a bit
tricky owing to -gN and -gdwarf-N having existing semantics, and
-g32/-g64/-gdwarf32/gdwarf64 being pretty subtly close to those flags
especially to have different semantics where -gdwarf-5 enables debug
info and chooses DWARF version 5, but -gdwarf32 doesn't enable debug
info, but chooses the 32 bit format to use if debug info is enabled by
some other flag.

- Dave

Re: DWARF64 gcc/clang flag discussion

[David Blaikie via Gcc]

On Mon, Nov 23, 2020 at 11:45 PM Jakub Jelinek  wrote:
>
> On Mon, Nov 23, 2020 at 06:38:16PM -0800, David Blaikie via Gcc wrote:
> > > I would pick -gdwarf32/-gdwarf64 (are we sure the DWARF spec will
> > > never reach version 32 or 64?
> > > maybe -g32 / -g64 similar to -m32/-m64 are good enough?)
> >
> > Any sense of a good way to break the tie/uncertainty?
> >
> > Alternatively: If Clang picks something here (likely from within this
> > range of candidates - though given I've got a fair bit of say on the
> > Clang side, and if left to me, I'd probably lean heavily on the
> > -fdwarf32/64 side), is it likely that choice will tend to be adopted
> > by GCC? I'd rather not get out of sync, but I expect a bit hard to get
> > a conclusion on the GCC side without patches in progress, etc. Got a
> > sense of who are the people who would likely be deciders/patch
> > approvers for such a naming choice on the GCC side?
>
> Depends on what it would choose.

Sure enough - I was more getting at "would Clang's choice here have
much/any influence on GCC's choice in the future"? (ie: Is GCC
interested in compatibility with Clang?)

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

I understand that the actual collision isn't likely - but the
proximity in phrasing seems liable to be confusing to users.
(especially if it has different semantics re: enabling debug info and
my understanding/reading of other threads was that folks were
generally in agreement that we should try to avoid having
debug-info-affecting flags that also enable debug info, instead trying
to keep them more orthogonal, I think?)

- Dave

Re: DWARF64 gcc/clang flag discussion

[David Blaikie via Gcc]

On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek  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  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)

- Dave

Re: DWARF64 gcc/clang flag discussion

[David Blaikie via Gcc]

On Wed, Nov 25, 2020 at 1:22 AM Richard Biener
 wrote:
>
> On Tue, Nov 24, 2020 at 7:38 PM David Blaikie  wrote:
> >
> > On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek  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  
> > > > > 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.

Any thoughts on this case - whether -gdwarf32/-gdwarf64 should imply -g?

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

-gdwarf-N sort of falls under this category, at least for backwards
compatibility - though whether it "selects a debuginfo format" might
be a bit open to interpretation. Where does -gdwarf32/-gdwarf64 fall
on that spectrum for you? I guess the important part is compatibility,
not whether it selects a debug info format or does something else.
There's no need for mechanical compatibility (though possibly for
human compatibility - having -gdwarf-4 enable -g but -gdwarf32 not
enable -g seems fairly subtle to me) here, but some folks on this
thread suggest -gdwarf32 should enable -g (Jakub and Jeff).

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

Oh. Seems a pity from a backwards (& sidewards with clang - though
we'll probably update ours to match to reduce that problem)
compatibility standpoint, but good to know!

- Dave

Re: DWARF64 gcc/clang flag discussion

[David Blaikie via Gcc]

On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich 
wrote:

> Thank you David for driving the conversation, sorry I was on vacation.
>

All good - really appreciate everyone chipping in whenever/however they can!


>
> I guess discussion is from perspective of having both flags
> gdwarf32/gdwarf64. In which case it's a valid question on whether they
> should imply -g like -gdwarf-#.
> But can this be viewed as only a -gdwarf64 flag, that is a qualifier to
> other debug flags that enable debug information? DWARF spec says that 32bit
> should be a default, and 64bit should be used rarely (paraphrasing). So
> when user enabled debug information the default expectation is that it will
> be 32bit. There is no real need for a flag to say "I want debug
> information, and I want it 32bit".
>

I'm not quite with you here, I think. I believe it's important to be able
to opt into and out of things at any point on the command line - because of
how complex build systems build up command lines. You might have a
-gdwarf64 set as a project default, but for some reason want to opt into
-gdwarf32 in other parts (perhaps you're building the debug info for your
interface library you intend to ship to clients who might only have DWARF32
support, but your library is big and needs DWARF64 for the rest). A general
architectural principle of most command line arguments to the compiler is
that they can be opted into/out of fairly symmetrically (hence all the
-*no-* variant flags).


> On the other hand, 64bit DWARF format must be enabled. So from users
> perspective it's "I want debug information enabled for particular DWARF
> version and level, oh and I want it to be 64bit".
>

But there's also the possibility of wanting to turn on DWARF64 for any
debug info in your build, but not necessarily wanting to turn on debug info
while doing so. Eg: you have a big build system, with a variety of users
and flags all over the place - maybe users opting in to -g2 on some files
and -g1 on others, and/or under different build modes. And the project as a
whole is reaching the DWARF64 tipping point and you'd like to say "if we're
generating DWARF, make it DWARF64". We've recently encountered this sort of
situation with -gsplit-dwarf and with -gdwarf-N (in switching to DWARFv5 we
had this situation where there's a big code base/build system with many
users, many uses of different -gN-type flags and it'd be impractical to go
and add -gdwarf-5 to all the -gN uses to make them all use DWARFv5, so we
added -fdebug-default-version=N (I might be misremembering the spelling) to
Clang to support this use case of "If we're generating DWARF, make it
DWARFv5")


> This also helps to avoid the scenario if user explicitly specifies debug
> level. The gcc documentation says
> "If you use multiple -g options, with or without level numbers, the last
> such option is the one that is effective."
> With complex, like buck, build systems with various config files, and hard
> coded overrides that's just asking to end up with debug level that might
> not be what user expects.
>

Not quite sure I'm following here - if -gdwarf64 does enable -g by default
it might be quite confusing in such a big complicated build system - where
a user actually wanted -gmlt or -g0 or some certain library or file, but it
got overriden by -gdwarf64. (or the inverse - does -gdwarf64 -g mean
DWARF32 again because that's the default? That's probably not what people
want most of the time (but sometimes they might want to opt back into
DWARF32 later in the command line)

- Dave


>
> Thank You
> Alex
>
> --
> *From:* David Blaikie 
> *Sent:* Wednesday, November 25, 2020 1:46 PM
> *To:* Richard Biener 
> *Cc:* Jakub Jelinek ; Mark Wielaard ;
> gcc@gcc.gnu.org ; ikud...@accesssoftek.com <
> ikud...@accesssoftek.com>; Alexander Yermolovich ;
> mask...@google.com 
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Wed, Nov 25, 2020 at 1:22 AM Richard Biener
>  wrote:
> >
> > On Tue, Nov 24, 2020 at 7:38 PM David Blaikie 
> wrote:
> > >
> > > On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek 
> 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 
> 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 u

Re: DWARF64 gcc/clang flag discussion

[David Blaikie via Gcc]

On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich 
wrote:

>
>
> --
> *From:* David Blaikie 
> *Sent:* Monday, November 30, 2020 12:09 PM
> *To:* Alexander Yermolovich 
> *Cc:* Richard Biener ; Jakub Jelinek <
> ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikud...@accesssoftek.com ;
> mask...@google.com 
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich 
> wrote:
>
> Thank you David for driving the conversation, sorry I was on vacation.
>
>
> All good - really appreciate everyone chipping in whenever/however they
> can!
>
>
>
> I guess discussion is from perspective of having both flags
> gdwarf32/gdwarf64. In which case it's a valid question on whether they
> should imply -g like -gdwarf-#.
> But can this be viewed as only a -gdwarf64 flag, that is a qualifier to
> other debug flags that enable debug information? DWARF spec says that 32bit
> should be a default, and 64bit should be used rarely (paraphrasing). So
> when user enabled debug information the default expectation is that it will
> be 32bit. There is no real need for a flag to say "I want debug
> information, and I want it 32bit".
>
>
> I'm not quite with you here, I think. I believe it's important to be able
> to opt into and out of things at any point on the command line - because of
> how complex build systems build up command lines. You might have a
> -gdwarf64 set as a project default, but for some reason want to opt into
> -gdwarf32 in other parts (perhaps you're building the debug info for your
> interface library you intend to ship to clients who might only have DWARF32
> support, but your library is big and needs DWARF64 for the rest). A general
> architectural principle of most command line arguments to the compiler is
> that they can be opted into/out of fairly symmetrically (hence all the
> -*no-* variant flags).
>
> [Alex] Ah I see, good point.
>
>
> On the other hand, 64bit DWARF format must be enabled. So from users
> perspective it's "I want debug information enabled for particular DWARF
> version and level, oh and I want it to be 64bit".
>
>
> But there's also the possibility of wanting to turn on DWARF64 for any
> debug info in your build, but not necessarily wanting to turn on debug info
> while doing so. Eg: you have a big build system, with a variety of users
> and flags all over the place - maybe users opting in to -g2 on some files
> and -g1 on others, and/or under different build modes. And the project as a
> whole is reaching the DWARF64 tipping point and you'd like to say "if we're
> generating DWARF, make it DWARF64". We've recently encountered this sort of
> situation with -gsplit-dwarf and with -gdwarf-N (in switching to DWARFv5 we
> had this situation where there's a big code base/build system with many
> users, many uses of different -gN-type flags and it'd be impractical to go
> and add -gdwarf-5 to all the -gN uses to make them all use DWARFv5, so we
> added -fdebug-default-version=N (I might be misremembering the spelling) to
> Clang to support this use case of "If we're generating DWARF, make it
> DWARFv5")
>
> [Alex] I think we are saying similar thing. The -gdwarf64 doesn't enable
> debug generation, but if it is enabled it will be 64bit. A "qualifier" of
> sorts.
>

OK. My concern there, though I think it's the preferable semantics for the
-gdwarf64 flag when considered in isolation, is now -gdwarf64 and -gdwarf-5
would have some fairly subtly different semantics (the latter enables debug
info and the former does not) in contrast to how close their spelling is.
(in addition to their general similarly maybe being a source of confusion -
even if the numbers aren't close to each other)




>
>
> This also helps to avoid the scenario if user explicitly specifies debug
> level. The gcc documentation says
> "If you use multiple -g options, with or without level numbers, the last
> such option is the one that is effective."
> With complex, like buck, build systems with various config files, and hard
> coded overrides that's just asking to end up with debug level that might
> not be what user expects.
>
>
> Not quite sure I'm following here - if -gdwarf64 does enable -g by default
> it might be quite confusing in such a big complicated build system - where
> a user actually wanted -gmlt or -g0 or some certain library or file, but it
> got overriden by -gdwarf64. (or the inverse - does -gdwarf64 -g mean
> DWARF32 again because that's the default? That's probably not what people
> want most of the time (but sometimes they might want to opt back into
> DWARF32 later in the command line)
>
> [Alex] Primarily from the debug level perspective. If user specifies -g0
> or -gmlt, and -gdwarf64 (assuming it enables -g), then depending on the
> order in command line where build system has put things user might end up
> with level of debug information they wanted, or with default -g.
>

Ah, you mean in the case

Re: DWARF64 gcc/clang flag discussion

[David Blaikie via Gcc]

On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich 
wrote:

>
>
> --
> *From:* David Blaikie 
> *Sent:* Tuesday, December 1, 2020 10:33 AM
> *To:* Alexander Yermolovich 
> *Cc:* Richard Biener ; Jakub Jelinek <
> ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikud...@accesssoftek.com ;
> mask...@google.com 
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
>
>
> On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich 
> wrote:
>
>
>
> --
> *From:* David Blaikie 
> *Sent:* Monday, November 30, 2020 12:09 PM
> *To:* Alexander Yermolovich 
> *Cc:* Richard Biener ; Jakub Jelinek <
> ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikud...@accesssoftek.com ;
> mask...@google.com 
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich 
> wrote:
>
> Thank you David for driving the conversation, sorry I was on vacation.
>
>
> All good - really appreciate everyone chipping in whenever/however they
> can!
>
>
>
> I guess discussion is from perspective of having both flags
> gdwarf32/gdwarf64. In which case it's a valid question on whether they
> should imply -g like -gdwarf-#.
> But can this be viewed as only a -gdwarf64 flag, that is a qualifier to
> other debug flags that enable debug information? DWARF spec says that 32bit
> should be a default, and 64bit should be used rarely (paraphrasing). So
> when user enabled debug information the default expectation is that it will
> be 32bit. There is no real need for a flag to say "I want debug
> information, and I want it 32bit".
>
>
> I'm not quite with you here, I think. I believe it's important to be able
> to opt into and out of things at any point on the command line - because of
> how complex build systems build up command lines. You might have a
> -gdwarf64 set as a project default, but for some reason want to opt into
> -gdwarf32 in other parts (perhaps you're building the debug info for your
> interface library you intend to ship to clients who might only have DWARF32
> support, but your library is big and needs DWARF64 for the rest). A general
> architectural principle of most command line arguments to the compiler is
> that they can be opted into/out of fairly symmetrically (hence all the
> -*no-* variant flags).
>
> [Alex] Ah I see, good point.
>
>
> On the other hand, 64bit DWARF format must be enabled. So from users
> perspective it's "I want debug information enabled for particular DWARF
> version and level, oh and I want it to be 64bit".
>
>
> But there's also the possibility of wanting to turn on DWARF64 for any
> debug info in your build, but not necessarily wanting to turn on debug info
> while doing so. Eg: you have a big build system, with a variety of users
> and flags all over the place - maybe users opting in to -g2 on some files
> and -g1 on others, and/or under different build modes. And the project as a
> whole is reaching the DWARF64 tipping point and you'd like to say "if we're
> generating DWARF, make it DWARF64". We've recently encountered this sort of
> situation with -gsplit-dwarf and with -gdwarf-N (in switching to DWARFv5 we
> had this situation where there's a big code base/build system with many
> users, many uses of different -gN-type flags and it'd be impractical to go
> and add -gdwarf-5 to all the -gN uses to make them all use DWARFv5, so we
> added -fdebug-default-version=N (I might be misremembering the spelling) to
> Clang to support this use case of "If we're generating DWARF, make it
> DWARFv5")
>
> [Alex] I think we are saying similar thing. The -gdwarf64 doesn't enable
> debug generation, but if it is enabled it will be 64bit. A "qualifier" of
> sorts.
>
>
> OK. My concern there, though I think it's the preferable semantics for the
> -gdwarf64 flag when considered in isolation, is now -gdwarf64 and -gdwarf-5
> would have some fairly subtly different semantics (the latter enables debug
> info and the former does not) in contrast to how close their spelling is.
> (in addition to their general similarly maybe being a source of confusion -
> even if the numbers aren't close to each other)
> [Alex] That is a good point, but I guess broader question is if precedence
> is not good, should we follow it? If it's clearly documented, might be OK.
> As my professor Brian Harvey said many, many, many moons ago during my
> undergrad: "RTFM". If my understanding of exchange on this thread is
> correct, there doesn't seem to be a consensus on this point.
>

Re: lacking consensus: yep. That's my understanding.

Admittedly my sort of wedge take on this is - why not use -f flags that
don't have the ambiguity/overlap with "maybe it enables debug info too". (&
maybe we could use -fdwarf32/64 in Clang, to avoid implementing
-gdwarf32/64 with a difference in behavior in terms of
also-enables-emission - then implement whatever semantics GCC ended up
picking) - well, "why not" because 

Re: DWARF64 gcc/clang flag discussion

[David Blaikie via Gcc]

On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich 
wrote:

>
>
> --
> *From:* David Blaikie 
> *Sent:* Wednesday, December 2, 2020 1:12 PM
> *To:* Alexander Yermolovich 
> *Cc:* Richard Biener ; Jakub Jelinek <
> ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikud...@accesssoftek.com ;
> mask...@google.com 
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
>
>
> On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich 
> wrote:
>
>
>
> --
> *From:* David Blaikie 
> *Sent:* Tuesday, December 1, 2020 10:33 AM
> *To:* Alexander Yermolovich 
> *Cc:* Richard Biener ; Jakub Jelinek <
> ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikud...@accesssoftek.com ;
> mask...@google.com 
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
>
>
> On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich 
> wrote:
>
>
>
> --
> *From:* David Blaikie 
> *Sent:* Monday, November 30, 2020 12:09 PM
> *To:* Alexander Yermolovich 
> *Cc:* Richard Biener ; Jakub Jelinek <
> ja...@redhat.com>; Mark Wielaard ; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikud...@accesssoftek.com ;
> mask...@google.com 
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich 
> wrote:
>
> Thank you David for driving the conversation, sorry I was on vacation.
>
>
> All good - really appreciate everyone chipping in whenever/however they
> can!
>
>
>
> I guess discussion is from perspective of having both flags
> gdwarf32/gdwarf64. In which case it's a valid question on whether they
> should imply -g like -gdwarf-#.
> But can this be viewed as only a -gdwarf64 flag, that is a qualifier to
> other debug flags that enable debug information? DWARF spec says that 32bit
> should be a default, and 64bit should be used rarely (paraphrasing). So
> when user enabled debug information the default expectation is that it will
> be 32bit. There is no real need for a flag to say "I want debug
> information, and I want it 32bit".
>
>
> I'm not quite with you here, I think. I believe it's important to be able
> to opt into and out of things at any point on the command line - because of
> how complex build systems build up command lines. You might have a
> -gdwarf64 set as a project default, but for some reason want to opt into
> -gdwarf32 in other parts (perhaps you're building the debug info for your
> interface library you intend to ship to clients who might only have DWARF32
> support, but your library is big and needs DWARF64 for the rest). A general
> architectural principle of most command line arguments to the compiler is
> that they can be opted into/out of fairly symmetrically (hence all the
> -*no-* variant flags).
>
> [Alex] Ah I see, good point.
>
>
> On the other hand, 64bit DWARF format must be enabled. So from users
> perspective it's "I want debug information enabled for particular DWARF
> version and level, oh and I want it to be 64bit".
>
>
> But there's also the possibility of wanting to turn on DWARF64 for any
> debug info in your build, but not necessarily wanting to turn on debug info
> while doing so. Eg: you have a big build system, with a variety of users
> and flags all over the place - maybe users opting in to -g2 on some files
> and -g1 on others, and/or under different build modes. And the project as a
> whole is reaching the DWARF64 tipping point and you'd like to say "if we're
> generating DWARF, make it DWARF64". We've recently encountered this sort of
> situation with -gsplit-dwarf and with -gdwarf-N (in switching to DWARFv5 we
> had this situation where there's a big code base/build system with many
> users, many uses of different -gN-type flags and it'd be impractical to go
> and add -gdwarf-5 to all the -gN uses to make them all use DWARFv5, so we
> added -fdebug-default-version=N (I might be misremembering the spelling) to
> Clang to support this use case of "If we're generating DWARF, make it
> DWARFv5")
>
> [Alex] I think we are saying similar thing. The -gdwarf64 doesn't enable
> debug generation, but if it is enabled it will be 64bit. A "qualifier" of
> sorts.
>
>
> OK. My concern there, though I think it's the preferable semantics for the
> -gdwarf64 flag when considered in isolation, is now -gdwarf64 and -gdwarf-5
> would have some fairly subtly different semantics (the latter enables debug
> info and the former does not) in contrast to how close their spelling is.
> (in addition to their general similarly maybe being a source of confusion -
> even if the numbers aren't close to each other)
> [Alex] That is a good point, but I guess broader question is if precedence
> is not good, should we follow it? If it's clearly documented, might be OK.
> As my professor Brian Harvey said many, many, many moons ago during my
> undergrad: "RTFM". If my understanding of exchange on this thread is
> correct, there doesn't seem to be a consensus on this point.
>

Re: DWARF64 gcc/clang flag discussion

[David Blaikie via Gcc]

Thanks for the context, all!

On Mon, Dec 7, 2020 at 3:22 AM Jakub Jelinek  wrote:

> On Mon, Dec 07, 2020 at 08:14:20AM +0100, Richard Biener via Gcc wrote:
> > > Sorry, just going around in circles a bit, I guess this may be a better
> > > summary:
> > >   If I had to pick a -g flag/semantic for this, I guess I'd pick
> > > -gdwarf32/64 without implied -g. I'd pick that if I knew GCC would
> > > implement it to match - but if GCC might go either way on implied -g, I
> > > think I'd rather avoid changing the semantics of the flag later on &
> use a
> > > different name GCC isn't likely to define different semantics for (and
> I'd
> > > probably pick -fdwarf32/64).
> > >
> > >
> > > There's an approved patch to add -gdwarf{32,64} not implying -g
> > > [Alex] Do you happen to have a link on hand to it?
> > >
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560734.html
>
> Note, the change is already in GCC trunk.
>
> Jakub
>
>

Naming flag for specifying the output file name for Binary Module Interface files

[David Blaikie via Gcc]

Over in https://reviews.llvm.org/D137059 we're discussing the naming
of a clang flag - would be good to have it be consistent with GCC.

The functionality is to name the BMI (.pcm in Clang's parlance) output
file when compiling a C++20 module.

Current proposal is to use `-fsave-std-cxx-module-file=` which is
certainly precise, but maybe a bit verbose. Clang has some other flags
related to modules that skip the std/cxx parts, and are just
`-fmodule-*` or `-fmodules-*`, so there's some precedent for that too.

Do GCC folks have any veto votes (is the currently proposed name
especially objectionable/wouldn't be acceptable in GCC) or preferences
(suggestions to add to the pool)?

Re: Naming flag for specifying the output file name for Binary Module Interface files

[David Blaikie via Gcc]

Thanks Iain for the summary/thanks everyone for the discussion!

On Fri, Dec 9, 2022 at 9:33 AM Iain Sandoe  wrote:
>
> Hello all.
>
> > On 9 Dec 2022, at 01:58, chuanqi.xcq  wrote:
> >
> > It looks like `-fmodule-file` is better from the discussion. So let's take 
> > it. Thanks for everyone here
>
> So FAOD (after this discussion) Chuanqi's current patchset implements the 
> following in clang:
>
> -fmodule-output
>
>   - this causes the BMI to be saved in the CWG with the basename of the 
> source file and a suffix of .pcm.
>
> -fmodule-output=
>
>  - this causes the BMI to be saved at the path specified.
>
> ===
>
> These facilities support build systems that do not use the P1184 interface to 
> map between module names and paths.
>
> cheers
> Iain
>
> >
> > Thanks,
> > Chuanqi
> > --
> > From:Nathan Sidwell 
> > Send Time:2022年12月8日(星期四) 01:00
> > To:Iain Sandoe ; GCC Development 
> > Cc:Jonathan Wakely ; chuanqi.xcq 
> > ; David Blaikie ; 
> > ben.boeckel 
> > Subject:Re: Naming flag for specifying the output file name for Binary 
> > Module Interface files
> >
> > On 12/7/22 11:58, Iain Sandoe wrote:
> > >
> > >
> > >> On 7 Dec 2022, at 16:52, Nathan Sidwell via Gcc  wrote:
> > >>
> > >> On 12/7/22 11:18, Iain Sandoe wrote:
> > >>
> > >>> I think it is reasonable to include c++ in the spelling, since other 
> > >>> languages supported by
> > >>> GCC (and clang in due course) have modules.
> > >>
> > >> I disagree (about the reasonableness part).  Other languages have 
> > >> modules, true, but if they want to name the output file, why not have 
> > >> the same option spelling?
> > >>
> > >> I.e. why are we considering:
> > >>
> > >>$compiler -fc++-module-file=bob foo.cc
> > >>$compiler -ffortran-module-file=bob foo.f77
> > >>
> > >> The language is being selected implicitly by the file suffix (or 
> > >> explictly via -X$lang).  There's no reason for some other option 
> > >> controlling an aspect of the compilation to rename the language.  We 
> > >> don't do it for language-specific warning options, and similar.  (i.e. 
> > >> no -f[no-]c++-type-aliasing vs -fc-type-aliasing, nor -Wc++-extra vs 
> > >> -Wc-extra[*]
> > >
> > > Fair points.
> > >
> > > Unfortunately (in case it has not already been mentioned in this thread) 
> > > ‘-fmodule-file=‘ is already taken and it means an input, not an output.  
> > > So, whatever we choose it needs to be distinct from that.
> >
> > Yes, that's why I suggested -fmodule-output=
> >
> > nathan
> >
> > --
> > Nathan Sidwell
>

Re: Naming flag for specifying the output file name for Binary Module Interface files

[David Blaikie via Gcc]

I think Nathan might've been asking not only about what currently
happens, but what we think should happen?

On Mon, Dec 12, 2022 at 7:11 PM chuanqi.xcq  wrote:
>
> Hi Nathan,
>
> > 1) Are these flags silently ignored, if no module output is to be 
> > generated? Or  is some kind of diagnostic generated?
>
> Currently, clang will generate the unused-command-line-argument warning for 
> this case:
>
> ```
> argument unused during compilation: '-fmodule-output' 
> [-Wunused-command-line-argument]
> ```

Is that consistent with `-o`? (I assume so, but don't know - I guess
there aren't many cases where `-o` is unused (maybe `-fsyntax-only`),
so that behavior might be a bit less well specified)

> > 2) what happens if you specify both -- do you get two outputs, a 
> > diagnostic, or
> is one silently selected?
>
> If someone specify both `-fmodule-output` and `-fmodule-output=/path`,
> the `-fmodule-output=/path` will be selected always no matter what the order 
> is.

This seems surprising/possibly wrong to me - do we have precedent from
other flags to draw from?

> And if multiple `-fmodule-output=/path` are specified, the last one will be 
> selected.
>
> > 3) What is the behaviour if compilation fails?  Does nothing happen to the 
> > file
> indicated (potentially leaving an older version there), or does the equivalent
> of 'rm -f $MODULE.pcm' happen?
>
> The module file will be deleted. The behavior is the same with `-o`.
>
> Thanks,
> Chuanqi
>
>
> --
> From:Nathan Sidwell 
> Send Time:2022年12月12日(星期一) 22:30
> To:Iain Sandoe ; GCC Development 
> Cc:Nathan Sidwell ; Jonathan Wakely 
> ; David Blaikie ; ben.boeckel 
> ; chuanqi.xcq 
> Subject:Re: Naming flag for specifying the output file name for Binary Module 
> Interface files
>
> On 12/9/22 12:33, Iain Sandoe wrote:
> > Hello all.
> >
> >> On 9 Dec 2022, at 01:58, chuanqi.xcq  wrote:
> >>
> >> It looks like `-fmodule-file` is better from the discussion. So let's take 
> >> it. Thanks for everyone here
> >
> > So FAOD (after this discussion) Chuanqi's current patchset implements the 
> > following in clang:
> >
> > -fmodule-output
> >
> >- this causes the BMI to be saved in the CWG with the basename of the 
> > source file and a suffix of .pcm.
> >
> > -fmodule-output=
> >
> >   - this causes the BMI to be saved at the path specified.
> >
>
> 1) Are these flags silently ignored, if no module output is to be generated? 
> Or
> is some kind of diagnostic generated?
>
> 2) what happens if you specify both -- do you get two outputs, a diagnostic, 
> or
> is one silently selected?
>
> 3) What is the behaviour if compilation fails?  Does nothing happen to the 
> file
> indicated (potentially leaving an older version there), or does the equivalent
> of 'rm -f $MODULE.pcm' happen?
>
> nathan
>
> --
> Nathan Sidwell
>
>

Re: Naming flag for specifying the output file name for Binary Module Interface files

[David Blaikie via Gcc]

On Wed, Dec 14, 2022 at 1:56 AM chuanqi.xcq  wrote:
>
> Hi David,
>
> > I think Nathan might've been asking not only about what currently
> happens, but what we think should happen?
>
> Yes.
>
> > Is that consistent with `-o`? (I assume so, but don't know - I guess
> there aren't many cases where `-o` is unused (maybe `-fsyntax-only`),
> so that behavior might be a bit less well specified)
>
> `-o` wouldn't emit a warning if it is not used. (with `-fsyntax-only` for 
> example).
> Since we want to make the behavior of `-fmodule-output` to be consistent with 
> `-o`.
> I've changed the behavior in https://reviews.llvm.org/D140001.
>
> > This seems surprising/possibly wrong to me - do we have precedent from
> other flags to draw from?
>
> I feel it makes sense since `-fmodule-output=` will provide more information 
> than `-fmodule-output`.
> So it is naturally to me that `-fmodule-output=`  has higher priority.
>
> For examples, I don't enumerate all the flags but I find the following cases 
> in minutes:
> - `-fpack-struct=` has higher priority than `-fpack-struct`.
> - `-fsave-optimization-record=` has higher priority than  
> `-fsave-optimization-record=`.
> - `-ftime-report=` has higher priority than `-ftime-report`.
> - `-ftime-trace=` has higher priority than `-ftime-trace`.
>
> So I think the bahavior should be correct.

Fair enough - thanks for the references!
Nathan - is that consistent with your preference/understanding/experience?

>
> Thanks,
> Chuanqi
>
>
> --
> From:David Blaikie 
> Send Time:2022年12月13日(星期二) 23:56
> To:chuanqi.xcq 
> Cc:Iain Sandoe ; GCC Development ; Nathan 
> Sidwell ; Jonathan Wakely ; 
> ben.boeckel 
> Subject:Re: Naming flag for specifying the output file name for Binary Module 
> Interface files
>
> I think Nathan might've been asking not only about what currently
> happens, but what we think should happen?
>
> On Mon, Dec 12, 2022 at 7:11 PM chuanqi.xcq  
> wrote:
> >
> > Hi Nathan,
> >
> > > 1) Are these flags silently ignored, if no module output is to be 
> > > generated? Or  is some kind of diagnostic generated?
> >
> > Currently, clang will generate the unused-command-line-argument warning for 
> > this case:
> >
> > ```
> > argument unused during compilation: '-fmodule-output' 
> > [-Wunused-command-line-argument]
> > ```
>
> Is that consistent with `-o`? (I assume so, but don't know - I guess
> there aren't many cases where `-o` is unused (maybe `-fsyntax-only`),
> so that behavior might be a bit less well specified)
>
> > > 2) what happens if you specify both -- do you get two outputs, a 
> > > diagnostic, or
> > is one silently selected?
> >
> > If someone specify both `-fmodule-output` and `-fmodule-output=/path`,
> > the `-fmodule-output=/path` will be selected always no matter what the 
> > order is.
>
> This seems surprising/possibly wrong to me - do we have precedent from
> other flags to draw from?
>
> > And if multiple `-fmodule-output=/path` are specified, the last one will be 
> > selected.
> >
> > > 3) What is the behaviour if compilation fails?  Does nothing happen to 
> > > the file
> > indicated (potentially leaving an older version there), or does the 
> > equivalent
> > of 'rm -f $MODULE.pcm' happen?
> >
> > The module file will be deleted. The behavior is the same with `-o`.
> >
> > Thanks,
> > Chuanqi
> >
> >
> > --
> > From:Nathan Sidwell 
> > Send Time:2022年12月12日(星期一) 22:30
> > To:Iain Sandoe ; GCC Development 
> > Cc:Nathan Sidwell ; Jonathan Wakely 
> > ; David Blaikie ; ben.boeckel 
> > ; chuanqi.xcq 
> > Subject:Re: Naming flag for specifying the output file name for Binary 
> > Module Interface files
> >
> > On 12/9/22 12:33, Iain Sandoe wrote:
> > > Hello all.
> > >
> > >> On 9 Dec 2022, at 01:58, chuanqi.xcq  wrote:
> > >>
> > >> It looks like `-fmodule-file` is better from the discussion. So let's 
> > >> take it. Thanks for everyone here
> > >
> > > So FAOD (after this discussion) Chuanqi's current patchset implements the 
> > > following in clang:
> > >
> > > -fmodule-output
> > >
> > >- this causes the BMI to be saved in the CWG with the basename of the 
> > > source file and a suffix of .pcm.
> > >
> > > -fmodule-output=
> > >
> > >   - this causes the BMI to be saved at the path specified.
> > >
> >
> > 1) Are these flags silently ignored, if no module output is to be 
> > generated? Or
> > is some kind of diagnostic generated?
> >
> > 2) what happens if you specify both -- do you get two outputs, a 
> > diagnostic, or
> > is one silently selected?
> >
> > 3) What is the behaviour if compilation fails?  Does nothing happen to the 
> > file
> > indicated (potentially leaving an older version there), or does the 
> > equivalent
> > of 'rm -f $MODULE.pcm' happen?
> >
> > nathan
> >
> > --
> > Nathan Sidwell
> >
> >
>
>