From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 40A573857C48 for ; Wed, 2 Sep 2020 11:12:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 40A573857C48 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 3558230278CD; Wed, 2 Sep 2020 13:12:54 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id C377C40006CA; Wed, 2 Sep 2020 13:12:54 +0200 (CEST) Message-ID: <020d26d5051df35808045d8a1e70e1c413fe1df8.camel@klomp.org> Subject: Re: Future debug options: -f* or -g*? From: Mark Wielaard To: David Blaikie Cc: Fangrui Song , gcc Mailing List , Lubos Lunak , Eric Botcazou Date: Wed, 02 Sep 2020 13:12:54 +0200 In-Reply-To: References: <20200709190329.eqtxxxtahd2zm3is@google.com> <20200709192820.gav5sndwnzfo7pws@google.com> <9c8af647-33ea-bd5c-a700-c113cf7741d7@acm.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 11:12:59 -0000 Hi David, On Mon, 2020-08-31 at 20:10 -0700, David Blaikie wrote: > Hey Mark - saw a little of/bits about your presentation at LPC 2020 GNU > Tools Track (& your thread on on the gdb list about debug_names). Wonderi= ng > if you (or anyone else you know who's contributing to debug info in GCC) > have some thoughts on this flag naming issue. It'd be great to get some > alignment between GCC and Clang here, so as we both add new flags going > forward, at least they're at least categorically consistent for users, ev= en > if we aren't necessarily implementing the exact same flags/flag names > (though in the -gsplit-dwarf case, it'd be good for any new semantics/nam= e > to match exactly). To be honest I don't have any deep insights here. Sadly it is just a bit of a mess. Not helped by the fact that some debugging formats, like DWARF have a number in their name (dwarf2) that might not reflect actually reflext the version of that format (except for it being not- dwarf1). That is why I was suggesting to use -fdwarf(32|64) instead of -gdwarf(32|64) to use for 32 bits vs 64 bits offsets in dwarf(2|3|4|5), because there are already too many -gdwarf[number] options. The idea of having any of the -fs not imply -g and having any of the -gs imply -g seems a good one. But in general I think these suboptions are all a bit nonsense though. They are great for tinkering and playing with corner cases of the debugging format. But I don't think we are helping real developers with them. To make any of them useful they should be in one of the standard options that people actually use. Nobody has time (or the specialized knowledge) to really care about all these suboptions. Once people feel they need to use any of these suboptions we already lost or the user has such specialized knowledge that they will know about specific changes in these options or between compilers. So just like we have -Wall or -Wextra has groups of warning options people are likely to use and we have -O1, -O2 and -O3 (I personally believe -flto should just be in -O3 instead of being a separate option), we should simply focus on making -g1, -g2 and -g3 have good defaults. Where -g1 is the minimum needed to do some profiling/tracing/debugging without needing to map all addresses back to source completely but can leave out full type trees for example, -g2 is the default for being able to do a useful interactive debugging session and -g3 adds some (expensive) extras like .debug_macros and maybe .debug_names, etc. With respect to -gsplit-dwarf I think it was (in hindsight) a mistake to put things in a separate (.dwo) file. It is a bit confusing to users and complicates build systems immensely. I am hoping to implement -gsplit-dwarf=3Dsingle using SHF_EXCLUDED for gcc and then make that the default. Cheers, Mark