DWARF64 gcc/clang flag discussion

DWARF64 gcc/clang flag discussion

[Alexander Yermolovich]

Hello

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<name> or -g<name>. 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?

Thank You
Alex

Re: DWARF64 gcc/clang flag discussion

[mark]

On Fri, Nov 20, 2020 at 08:22:26PM +0000, 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<name> or -g<name>. 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.

Cheers,

Mark

Re: DWARF64 gcc/clang flag discussion

[Richard Biener]

On Sat, Nov 21, 2020 at 1:21 AM mark@klomp.org <mark@klomp.org> wrote:
>
> On Fri, Nov 20, 2020 at 08:22:26PM +0000, 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<name> or -g<name>. 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?)

Richard.

> Cheers,
>
> Mark

Re: DWARF64 gcc/clang flag discussion

[David Blaikie]

On Mon, Nov 23, 2020 at 12:32 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Sat, Nov 21, 2020 at 1:21 AM mark@klomp.org <mark@klomp.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 08:22:26PM +0000, 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<name> or -g<name>. 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

[Jeff Law]

On 11/23/20 7:38 PM, David Blaikie via Gcc wrote:
> On Mon, Nov 23, 2020 at 12:32 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Sat, Nov 21, 2020 at 1:21 AM mark@klomp.org <mark@klomp.org> wrote:
>>> On Fri, Nov 20, 2020 at 08:22:26PM +0000, 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<name> or -g<name>. 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.

jeff

Re: DWARF64 gcc/clang flag discussion

[David Blaikie]

On Mon, Nov 23, 2020 at 6:59 PM Jeff Law <law@redhat.com> wrote:
>
>
>
> On 11/23/20 7:38 PM, David Blaikie via Gcc wrote:
> > On Mon, Nov 23, 2020 at 12:32 AM Richard Biener
> > <richard.guenther@gmail.com> wrote:
> >> On Sat, Nov 21, 2020 at 1:21 AM mark@klomp.org <mark@klomp.org> wrote:
> >>> On Fri, Nov 20, 2020 at 08:22:26PM +0000, 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<name> or -g<name>. 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

[Jeff Law]

On 11/23/20 8:03 PM, David Blaikie wrote:
> On Mon, Nov 23, 2020 at 6:59 PM Jeff Law <law@redhat.com> wrote:
>>
>>
>> On 11/23/20 7:38 PM, David Blaikie via Gcc wrote:
>>> On Mon, Nov 23, 2020 at 12:32 AM Richard Biener
>>> <richard.guenther@gmail.com> wrote:
>>>> On Sat, Nov 21, 2020 at 1:21 AM mark@klomp.org <mark@klomp.org> wrote:
>>>>> On Fri, Nov 20, 2020 at 08:22:26PM +0000, 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<name> or -g<name>. 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"?
Yes.  While there are examples where that historical model hasn't been
followed, I don't think that's a good reason to make it worse than it
already is.  I still think it belongs in the -g namespace.

jeff

Re: DWARF64 gcc/clang flag discussion

[Jakub Jelinek]

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

	Jakub

Re: DWARF64 gcc/clang flag discussion

[Richard Biener]

On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek <jakub@redhat.com> 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.
> 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.

Richard.

>         Jakub
>

Re: DWARF64 gcc/clang flag discussion

[Mark Wielaard]

Hi,

On Tue, 2020-11-24 at 08:50 +0100, Richard Biener wrote:
> On Tue, Nov 24, 2020 at 8:45 AM Jakub Jelinek <jakub@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.

Cheers,

Mark

Re: DWARF64 gcc/clang flag discussion

[Jakub Jelinek]

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

That said, for -gdwarf32/64, I think it is more sensible to enable debug
info than not to.

	Jakub

Re: DWARF64 gcc/clang flag discussion

[Jeff Law]

On 11/24/20 4:11 AM, Jakub Jelinek via Gcc 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 <jakub@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.
>
> That said, for -gdwarf32/64, I think it is more sensible to enable debug
> info than not to.
That works for me.
jeff

Re: DWARF64 gcc/clang flag discussion

[David Blaikie]

On Mon, Nov 23, 2020 at 11:45 PM Jakub Jelinek <jakub@redhat.com> 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]

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

- Dave

Re: DWARF64 gcc/clang flag discussion

[Eric Botcazou]

> 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'd say yes, but this criterion comes second after consistency with itself.
The latter dictates a -g switch so, once this is established, what -g switch 
can indeed be coordinated.

-- 
Eric Botcazou

Re: DWARF64 gcc/clang flag discussion

[Richard Biener]

On Tue, Nov 24, 2020 at 7:38 PM David Blaikie <dblaikie@gmail.com> wrote:
>
> On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek <jakub@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 <jakub@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

Re: DWARF64 gcc/clang flag discussion

[David Blaikie]

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

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

[Alexander Yermolovich]

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

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

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.

Thank You
Alex

________________________________
From: David Blaikie <dblaikie@gmail.com>
Sent: Wednesday, November 25, 2020 1:46 PM
To: Richard Biener <richard.guenther@gmail.com>
Cc: Jakub Jelinek <jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>; Alexander Yermolovich <ayermolo@fb.com>; maskray@google.com <maskray@google.com>
Subject: Re: DWARF64 gcc/clang flag discussion

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

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

[Fāng-ruì Sòng]

On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@fb.com> wrote:
>
> Thank you David for driving the conversation, sorry I was on vacation.
>
> 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". 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".
>
> 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.
>
> Thank You
> Alex

Personally I also prefer that -gdwarf64 does not implies debug info
emission, and wish we can continue using -g for future debug options
(not having to abandon -g just because a few -g have the undesired
side effect).

The usage of -gdwarf64 is niche. If the side effect of -gdwarf-N,
-ggdb, -gstabs, -gxcoff, etc is clearly documented on
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
I hope -gdwarf64 not implying debug info emission is fine.

Clang from 10.0 onwards supports -fdebug-default-version
(https://reviews.llvm.org/D69822) for a -gdwarf-N variant which does
not imply debug info emission.

>
> ________________________________
> From: David Blaikie <dblaikie@gmail.com>
> Sent: Wednesday, November 25, 2020 1:46 PM
> To: Richard Biener <richard.guenther@gmail.com>
> Cc: Jakub Jelinek <jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>; Alexander Yermolovich <ayermolo@fb.com>; maskray@google.com <maskray@google.com>
> Subject: Re: DWARF64 gcc/clang flag discussion
>
> On Wed, Nov 25, 2020 at 1:22 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
> >
> > On Tue, Nov 24, 2020 at 7:38 PM David Blaikie <dblaikie@gmail.com> wrote:
> > >
> > > On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek <jakub@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 <jakub@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.
>
> 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]

On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@fb.com>
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 <dblaikie@gmail.com>
> *Sent:* Wednesday, November 25, 2020 1:46 PM
> *To:* Richard Biener <richard.guenther@gmail.com>
> *Cc:* Jakub Jelinek <jakub@redhat.com>; Mark Wielaard <mark@klomp.org>;
> gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <
> ikudrin@accesssoftek.com>; Alexander Yermolovich <ayermolo@fb.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Wed, Nov 25, 2020 at 1:22 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
> >
> > On Tue, Nov 24, 2020 at 7:38 PM David Blaikie <dblaikie@gmail.com>
> wrote:
> > >
> > > On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek <jakub@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 <jakub@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.
>
> 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

[Mark Wielaard]

On Mon, Nov 30, 2020 at 07:35:36PM +0000, Alexander Yermolovich via Gcc wrote:
> 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". 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".

GCC already support DWARF64 because some gcc architectures already
default to DWARF64. They #define DWARF_OFFSET_SIZE PTR_SIZE. We
currently don't have an option to use DWARF32 for those
arches. -gdwarf32 would be that flag.

And in general I think you want composable command line flags where a
later flag can override an earlier flag.

Cheers,

Mark

Re: DWARF64 gcc/clang flag discussion

[Alexander Yermolovich]

________________________________
From: David Blaikie <dblaikie@gmail.com>
Sent: Monday, November 30, 2020 12:09 PM
To: Alexander Yermolovich <ayermolo@fb.com>
Cc: Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>; maskray@google.com <maskray@google.com>
Subject: Re: DWARF64 gcc/clang flag discussion

On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>> 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.

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.
Basically, I am arguing for case of -gdwarf32/64 not enabling -g.

- Dave


Thank You
Alex

________________________________
From: David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>>
Sent: Wednesday, November 25, 2020 1:46 PM
To: Richard Biener <richard.guenther@gmail.com<mailto:richard.guenther@gmail.com>>
Cc: Jakub Jelinek <jakub@redhat.com<mailto:jakub@redhat.com>>; Mark Wielaard <mark@klomp.org<mailto:mark@klomp.org>>; gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org> <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>; ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com> <ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com>>; Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>>; maskray@google.com<mailto:maskray@google.com> <maskray@google.com<mailto:maskray@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion

On Wed, Nov 25, 2020 at 1:22 AM Richard Biener
<richard.guenther@gmail.com<mailto:richard.guenther@gmail.com>> wrote:
>
> On Tue, Nov 24, 2020 at 7:38 PM David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>> wrote:
> >
> > On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek <jakub@redhat.com<mailto:jakub@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 <jakub@redhat.com<mailto:jakub@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.

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]

On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich <ayermolo@fb.com>
wrote:

>
>
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Monday, November 30, 2020 12:09 PM
> *To:* Alexander Yermolovich <ayermolo@fb.com>
> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@fb.com>
> 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 where -gdwarf64 is debug-info-enabling, then "-g0
-gdwarf64" and "-gdwarf64 -g0" would have different semantics, but if we
make -gdwarf64 a qualifier then those two scenarios won't have different
semantics (both will be -g0) and that would be a good thing for users?
Yeah, I'm with you there.


> Basically, I am arguing for case of -gdwarf32/64 not enabling -g.
>
> - Dave
>
>
>
> Thank You
> Alex
>
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Wednesday, November 25, 2020 1:46 PM
> *To:* Richard Biener <richard.guenther@gmail.com>
> *Cc:* Jakub Jelinek <jakub@redhat.com>; Mark Wielaard <mark@klomp.org>;
> gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <
> ikudrin@accesssoftek.com>; Alexander Yermolovich <ayermolo@fb.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Wed, Nov 25, 2020 at 1:22 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
> >
> > On Tue, Nov 24, 2020 at 7:38 PM David Blaikie <dblaikie@gmail.com>
> wrote:
> > >
> > > On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek <jakub@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 <jakub@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.
>
> 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

[Alexander Yermolovich]

________________________________
From: David Blaikie <dblaikie@gmail.com>
Sent: Tuesday, December 1, 2020 10:33 AM
To: Alexander Yermolovich <ayermolo@fb.com>
Cc: Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>; maskray@google.com <maskray@google.com>
Subject: Re: DWARF64 gcc/clang flag discussion



On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>> wrote:


________________________________
From: David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>>
Sent: Monday, November 30, 2020 12:09 PM
To: Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>>
Cc: Richard Biener <richard.guenther@gmail.com<mailto:richard.guenther@gmail.com>>; Jakub Jelinek <jakub@redhat.com<mailto:jakub@redhat.com>>; Mark Wielaard <mark@klomp.org<mailto:mark@klomp.org>>; gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org> <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>; ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com> <ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com>>; maskray@google.com<mailto:maskray@google.com> <maskray@google.com<mailto:maskray@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion

On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>> 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.



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 where -gdwarf64 is debug-info-enabling, then "-g0 -gdwarf64" and "-gdwarf64 -g0" would have different semantics, but if we make -gdwarf64 a qualifier then those two scenarios won't have different semantics (both will be -g0) and that would be a good thing for users? Yeah, I'm with you there.
[Alex] Yep, exactly.

Basically, I am arguing for case of -gdwarf32/64 not enabling -g.

- Dave


Thank You
Alex

________________________________
From: David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>>
Sent: Wednesday, November 25, 2020 1:46 PM
To: Richard Biener <richard.guenther@gmail.com<mailto:richard.guenther@gmail.com>>
Cc: Jakub Jelinek <jakub@redhat.com<mailto:jakub@redhat.com>>; Mark Wielaard <mark@klomp.org<mailto:mark@klomp.org>>; gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org> <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>; ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com> <ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com>>; Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>>; maskray@google.com<mailto:maskray@google.com> <maskray@google.com<mailto:maskray@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion

On Wed, Nov 25, 2020 at 1:22 AM Richard Biener
<richard.guenther@gmail.com<mailto:richard.guenther@gmail.com>> wrote:
>
> On Tue, Nov 24, 2020 at 7:38 PM David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>> wrote:
> >
> > On Tue, Nov 24, 2020 at 3:11 AM Jakub Jelinek <jakub@redhat.com<mailto:jakub@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 <jakub@redhat.com<mailto:jakub@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.

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]

On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich <ayermolo@fb.com>
wrote:

>
>
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Tuesday, December 1, 2020 10:33 AM
> *To:* Alexander Yermolovich <ayermolo@fb.com>
> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
>
>
> On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich <ayermolo@fb.com>
> wrote:
>
>
>
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Monday, November 30, 2020 12:09 PM
> *To:* Alexander Yermolovich <ayermolo@fb.com>
> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@fb.com>
> 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 of the general take that debug info
flags should be "-g", fair enough.

So, yeah, I'm still pretty undecided about how Clang should move forward
with this in the immediate future.

- Dave

Re: DWARF64 gcc/clang flag discussion

[Alexander Yermolovich]

________________________________
From: David Blaikie <dblaikie@gmail.com>
Sent: Wednesday, December 2, 2020 1:12 PM
To: Alexander Yermolovich <ayermolo@fb.com>
Cc: Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>; maskray@google.com <maskray@google.com>
Subject: Re: DWARF64 gcc/clang flag discussion



On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>> wrote:


________________________________
From: David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>>
Sent: Tuesday, December 1, 2020 10:33 AM
To: Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>>
Cc: Richard Biener <richard.guenther@gmail.com<mailto:richard.guenther@gmail.com>>; Jakub Jelinek <jakub@redhat.com<mailto:jakub@redhat.com>>; Mark Wielaard <mark@klomp.org<mailto:mark@klomp.org>>; gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org> <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>; ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com> <ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com>>; maskray@google.com<mailto:maskray@google.com> <maskray@google.com<mailto:maskray@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion



On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>> wrote:


________________________________
From: David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>>
Sent: Monday, November 30, 2020 12:09 PM
To: Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>>
Cc: Richard Biener <richard.guenther@gmail.com<mailto:richard.guenther@gmail.com>>; Jakub Jelinek <jakub@redhat.com<mailto:jakub@redhat.com>>; Mark Wielaard <mark@klomp.org<mailto:mark@klomp.org>>; gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org> <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>; ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com> <ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com>>; maskray@google.com<mailto:maskray@google.com> <maskray@google.com<mailto:maskray@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion

On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>> 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 of the general take that debug info flags should be "-g", fair enough.

So, yeah, I'm still pretty undecided about how Clang should move forward with this in the immediate future.
[Alex] Well if there is no consensus maybe clang can trail blaze. 🙂

- Dave

Re: DWARF64 gcc/clang flag discussion

[David Blaikie]

On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich <ayermolo@fb.com>
wrote:

>
>
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Wednesday, December 2, 2020 1:12 PM
> *To:* Alexander Yermolovich <ayermolo@fb.com>
> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
>
>
> On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich <ayermolo@fb.com>
> wrote:
>
>
>
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Tuesday, December 1, 2020 10:33 AM
> *To:* Alexander Yermolovich <ayermolo@fb.com>
> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
>
>
> On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich <ayermolo@fb.com>
> wrote:
>
>
>
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Monday, November 30, 2020 12:09 PM
> *To:* Alexander Yermolovich <ayermolo@fb.com>
> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@fb.com>
> 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 of the general take that debug info
> flags should be "-g", fair enough.
>
> So, yeah, I'm still pretty undecided about how Clang should move forward
> with this in the immediate future.
> [Alex] Well if there is no consensus maybe clang can trail blaze. 🙂
>

My concern with doing so is both that GCC might not make the same decision,
leading to differences in flag semantics (and my other concerns about the
available options that lean towards the -g* style naming and the
ambiguities around composability or implied -g in general and in particular
with the likely names here and how close they are to existing names that do
imply -g, hence my personal preference towards the -f names). Might end up
going with the -f names out of a combination of my desire for clear
designation of composability, and sidestepping the issue of GCC
compatibility in the future if GCC's going to pick a -g name and semantics
(implied -g or otherwise) anyway. This does mean I/we/clang loses a chance
to perhaps somewhat more heavily (than just my words here) influence GCC's
flag choice (eg: by Clang choosing the -g* naming and making it composable,
for instance), but avoids the chance of divergent behavior between the two
compilers, or breaking backwards compatibility to maintain compatibility.

All up I just don't have great feelings about any of the paths forward,
really. I think -fdwarf32/64 is the better option for users, that
-gdwarf32/64 implying -g would be unfortunate (composability is valuable)
and -gdwarf32/64 being composable would be pretty confusing to users given
-gdwarf-N isn't composable & they are very similar flags/spellings
(similarly for -g32/64 compared to -gN).


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

- Dave

>

Re: DWARF64 gcc/clang flag discussion

[Richard Biener]

On Thu, Dec 3, 2020 at 6:52 PM David Blaikie <dblaikie@gmail.com> wrote:

>
>
> On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich <ayermolo@fb.com>
> wrote:
>
>>
>>
>> ------------------------------
>> *From:* David Blaikie <dblaikie@gmail.com>
>> *Sent:* Wednesday, December 2, 2020 1:12 PM
>> *To:* Alexander Yermolovich <ayermolo@fb.com>
>> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
>> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
>> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
>> maskray@google.com <maskray@google.com>
>> *Subject:* Re: DWARF64 gcc/clang flag discussion
>>
>>
>>
>> On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich <ayermolo@fb.com>
>> wrote:
>>
>>
>>
>> ------------------------------
>> *From:* David Blaikie <dblaikie@gmail.com>
>> *Sent:* Tuesday, December 1, 2020 10:33 AM
>> *To:* Alexander Yermolovich <ayermolo@fb.com>
>> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
>> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
>> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
>> maskray@google.com <maskray@google.com>
>> *Subject:* Re: DWARF64 gcc/clang flag discussion
>>
>>
>>
>> On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich <ayermolo@fb.com>
>> wrote:
>>
>>
>>
>> ------------------------------
>> *From:* David Blaikie <dblaikie@gmail.com>
>> *Sent:* Monday, November 30, 2020 12:09 PM
>> *To:* Alexander Yermolovich <ayermolo@fb.com>
>> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
>> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
>> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
>> maskray@google.com <maskray@google.com>
>> *Subject:* Re: DWARF64 gcc/clang flag discussion
>>
>> On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@fb.com>
>> 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 of the general take that debug info
>> flags should be "-g", fair enough.
>>
>> So, yeah, I'm still pretty undecided about how Clang should move forward
>> with this in the immediate future.
>> [Alex] Well if there is no consensus maybe clang can trail blaze. 🙂
>>
>
> My concern with doing so is both that GCC might not make the same
> decision, leading to differences in flag semantics (and my other concerns
> about the available options that lean towards the -g* style naming and the
> ambiguities around composability or implied -g in general and in particular
> with the likely names here and how close they are to existing names that do
> imply -g, hence my personal preference towards the -f names). Might end up
> going with the -f names out of a combination of my desire for clear
> designation of composability, and sidestepping the issue of GCC
> compatibility in the future if GCC's going to pick a -g name and semantics
> (implied -g or otherwise) anyway. This does mean I/we/clang loses a chance
> to perhaps somewhat more heavily (than just my words here) influence GCC's
> flag choice (eg: by Clang choosing the -g* naming and making it composable,
> for instance), but avoids the chance of divergent behavior between the two
> compilers, or breaking backwards compatibility to maintain compatibility.
>
> All up I just don't have great feelings about any of the paths forward,
> really. I think -fdwarf32/64 is the better option for users, that
> -gdwarf32/64 implying -g would be unfortunate (composability is valuable)
> and -gdwarf32/64 being composable would be pretty confusing to users given
> -gdwarf-N isn't composable & they are very similar flags/spellings
> (similarly for -g32/64 compared to -gN).
>
>
> 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

Richard.


>
> - Dave
>
>>

Re: DWARF64 gcc/clang flag discussion

[Alexander Yermolovich]

________________________________
From: Richard Biener <richard.guenther@gmail.com>
Sent: Friday, December 4, 2020 12:36 AM
To: David Blaikie <dblaikie@gmail.com>
Cc: Alexander Yermolovich <ayermolo@fb.com>; Jakub Jelinek <jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>; maskray@google.com <maskray@google.com>
Subject: Re: DWARF64 gcc/clang flag discussion

On Thu, Dec 3, 2020 at 6:52 PM David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>> wrote:


On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>> wrote:


________________________________
From: David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>>
Sent: Wednesday, December 2, 2020 1:12 PM
To: Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>>
Cc: Richard Biener <richard.guenther@gmail.com<mailto:richard.guenther@gmail.com>>; Jakub Jelinek <jakub@redhat.com<mailto:jakub@redhat.com>>; Mark Wielaard <mark@klomp.org<mailto:mark@klomp.org>>; gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org> <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>; ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com> <ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com>>; maskray@google.com<mailto:maskray@google.com> <maskray@google.com<mailto:maskray@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion



On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>> wrote:


________________________________
From: David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>>
Sent: Tuesday, December 1, 2020 10:33 AM
To: Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>>
Cc: Richard Biener <richard.guenther@gmail.com<mailto:richard.guenther@gmail.com>>; Jakub Jelinek <jakub@redhat.com<mailto:jakub@redhat.com>>; Mark Wielaard <mark@klomp.org<mailto:mark@klomp.org>>; gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org> <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>; ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com> <ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com>>; maskray@google.com<mailto:maskray@google.com> <maskray@google.com<mailto:maskray@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion



On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>> wrote:


________________________________
From: David Blaikie <dblaikie@gmail.com<mailto:dblaikie@gmail.com>>
Sent: Monday, November 30, 2020 12:09 PM
To: Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>>
Cc: Richard Biener <richard.guenther@gmail.com<mailto:richard.guenther@gmail.com>>; Jakub Jelinek <jakub@redhat.com<mailto:jakub@redhat.com>>; Mark Wielaard <mark@klomp.org<mailto:mark@klomp.org>>; gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org> <gcc@gcc.gnu.org<mailto:gcc@gcc.gnu.org>>; ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com> <ikudrin@accesssoftek.com<mailto:ikudrin@accesssoftek.com>>; maskray@google.com<mailto:maskray@google.com> <maskray@google.com<mailto:maskray@google.com>>
Subject: Re: DWARF64 gcc/clang flag discussion

On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@fb.com<mailto:ayermolo@fb.com>> 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 of the general take that debug info flags should be "-g", fair enough.

So, yeah, I'm still pretty undecided about how Clang should move forward with this in the immediate future.
[Alex] Well if there is no consensus maybe clang can trail blaze. 🙂

My concern with doing so is both that GCC might not make the same decision, leading to differences in flag semantics (and my other concerns about the available options that lean towards the -g* style naming and the ambiguities around composability or implied -g in general and in particular with the likely names here and how close they are to existing names that do imply -g, hence my personal preference towards the -f names). Might end up going with the -f names out of a combination of my desire for clear designation of composability, and sidestepping the issue of GCC compatibility in the future if GCC's going to pick a -g name and semantics (implied -g or otherwise) anyway. This does mean I/we/clang loses a chance to perhaps somewhat more heavily (than just my words here) influence GCC's flag choice (eg: by Clang choosing the -g* naming and making it composable, for instance), but avoids the chance of divergent behavior between the two compilers, or breaking backwards compatibility to maintain compatibility.

All up I just don't have great feelings about any of the paths forward, really. I think -fdwarf32/64 is the better option for users, that -gdwarf32/64 implying -g would be unfortunate (composability is valuable) and -gdwarf32/64 being composable would be pretty confusing to users given -gdwarf-N isn't composable & they are very similar flags/spellings (similarly for -g32/64 compared to -gN).


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?

Richard.


- Dave

Re: DWARF64 gcc/clang flag discussion

[Richard Biener]

On Fri, Dec 4, 2020 at 7:01 PM Alexander Yermolovich <ayermolo@fb.com>
wrote:

>
>
> ------------------------------
> *From:* Richard Biener <richard.guenther@gmail.com>
> *Sent:* Friday, December 4, 2020 12:36 AM
> *To:* David Blaikie <dblaikie@gmail.com>
> *Cc:* Alexander Yermolovich <ayermolo@fb.com>; Jakub Jelinek <
> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Thu, Dec 3, 2020 at 6:52 PM David Blaikie <dblaikie@gmail.com> wrote:
>
>
>
> On Wed, Dec 2, 2020 at 5:10 PM Alexander Yermolovich <ayermolo@fb.com>
> wrote:
>
>
>
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Wednesday, December 2, 2020 1:12 PM
> *To:* Alexander Yermolovich <ayermolo@fb.com>
> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
>
>
> On Wed, Dec 2, 2020 at 10:44 AM Alexander Yermolovich <ayermolo@fb.com>
> wrote:
>
>
>
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Tuesday, December 1, 2020 10:33 AM
> *To:* Alexander Yermolovich <ayermolo@fb.com>
> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
>
>
> On Mon, Nov 30, 2020 at 5:04 PM Alexander Yermolovich <ayermolo@fb.com>
> wrote:
>
>
>
> ------------------------------
> *From:* David Blaikie <dblaikie@gmail.com>
> *Sent:* Monday, November 30, 2020 12:09 PM
> *To:* Alexander Yermolovich <ayermolo@fb.com>
> *Cc:* Richard Biener <richard.guenther@gmail.com>; Jakub Jelinek <
> jakub@redhat.com>; Mark Wielaard <mark@klomp.org>; gcc@gcc.gnu.org <
> gcc@gcc.gnu.org>; ikudrin@accesssoftek.com <ikudrin@accesssoftek.com>;
> maskray@google.com <maskray@google.com>
> *Subject:* Re: DWARF64 gcc/clang flag discussion
>
> On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich <ayermolo@fb.com>
> 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 of the general take that debug info
> flags should be "-g", fair enough.
>
> So, yeah, I'm still pretty undecided about how Clang should move forward
> with this in the immediate future.
> [Alex] Well if there is no consensus maybe clang can trail blaze. 🙂
>
>
> My concern with doing so is both that GCC might not make the same
> decision, leading to differences in flag semantics (and my other concerns
> about the available options that lean towards the -g* style naming and the
> ambiguities around composability or implied -g in general and in particular
> with the likely names here and how close they are to existing names that do
> imply -g, hence my personal preference towards the -f names). Might end up
> going with the -f names out of a combination of my desire for clear
> designation of composability, and sidestepping the issue of GCC
> compatibility in the future if GCC's going to pick a -g name and semantics
> (implied -g or otherwise) anyway. This does mean I/we/clang loses a chance
> to perhaps somewhat more heavily (than just my words here) influence GCC's
> flag choice (eg: by Clang choosing the -g* naming and making it composable,
> for instance), but avoids the chance of divergent behavior between the two
> compilers, or breaking backwards compatibility to maintain compatibility.
>
> All up I just don't have great feelings about any of the paths forward,
> really. I think -fdwarf32/64 is the better option for users, that
> -gdwarf32/64 implying -g would be unfortunate (composability is valuable)
> and -gdwarf32/64 being composable would be pretty confusing to users given
> -gdwarf-N isn't composable & they are very similar flags/spellings
> (similarly for -g32/64 compared to -gN).
>
>
> 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


> Richard.
>
>
>
> - Dave
>
>

Re: DWARF64 gcc/clang flag discussion

[Jakub Jelinek]

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

Re: DWARF64 gcc/clang flag discussion

[David Blaikie]

Thanks for the context, all!

On Mon, Dec 7, 2020 at 3:22 AM Jakub Jelinek <jakub@redhat.com> 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
>
>