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"? (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
