On 11/23/20 8:03 PM, David Blaikie wrote:
> On Mon, Nov 23, 2020 at 6:59 PM Jeff Law <l...@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.guent...@gmail.com> wrote:
>>>> On Sat, Nov 21, 2020 at 1:21 AM m...@klomp.org <m...@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
