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