From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) by sourceware.org (Postfix) with ESMTPS id 6FB1C386F43B for ; Wed, 2 Sep 2020 22:33:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6FB1C386F43B Received: by mail-il1-x129.google.com with SMTP id q6so657004ild.12 for ; Wed, 02 Sep 2020 15:33:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o91z3lKyqrLtl0TWH+Fit55k0gcMJNVpDoRELgcY8N4=; b=oLiJ5pNbzdNuiW+vATV1sa+Vh4SnzW8ZSSk+kpOqq8FIYQbOeCluGdQgnWsPugMyKv I9c/bwxKVLIV9F2dRUsgvWnCljWI6squfCieKERoFC0rwMy0l3kZGlh4adF+Ye2rPwSG ieHMu5LHk4Pj3MdJ8XoWJojQj7A5vo3mZMrur58b7skG3IXmh9zHHDgi2Q6fn2Ssf3lW Slstm9v0cEcleCcPWy1XD7CHw8o+WenWAqv2gHwDp2SAQbmHEDY81I2VFfA61nN4Z+Eb kaA0IEGROoAu7STNl5/KAfs0RMVHia00CnJ+V1OymQ3A88wAPT04kncWKVOlxr0rTZXX PEJA== X-Gm-Message-State: AOAM533jOpdOtDLT01fECaOoNemlciLNfYAVfqgNrCQLwjOdip1J5DkT 1wdBIbGabjmBunq9lvXXaCgqXKArVjF7qmguHZ8= X-Google-Smtp-Source: ABdhPJzmqDaGJWR7ME+5vdb57liZhDWy+jl7C+ePOZoqGgv1dg4fjKPw2kV+glBz0lL3uG6liBLv5gAzmiFdSaUul0s= X-Received: by 2002:a92:c5ac:: with SMTP id r12mr371686ilt.274.1599085987728; Wed, 02 Sep 2020 15:33:07 -0700 (PDT) MIME-Version: 1.0 References: <20200709190329.eqtxxxtahd2zm3is@google.com> <20200709192820.gav5sndwnzfo7pws@google.com> <9c8af647-33ea-bd5c-a700-c113cf7741d7@acm.org> <020d26d5051df35808045d8a1e70e1c413fe1df8.camel@klomp.org> In-Reply-To: <020d26d5051df35808045d8a1e70e1c413fe1df8.camel@klomp.org> From: David Blaikie Date: Wed, 2 Sep 2020 15:32:56 -0700 Message-ID: Subject: Re: Future debug options: -f* or -g*? To: Mark Wielaard Cc: Fangrui Song , gcc Mailing List , Lubos Lunak , Eric Botcazou X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 22:33:10 -0000 On Wed, Sep 2, 2020 at 4:12 AM Mark Wielaard wrote: > 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). > Wondering > > 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, > even > > 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/name > > to match exactly). > > To be honest I don't have any deep insights here. Sadly it is just a > bit of a mess. Happen to know any other interested parties (other GCC DWARF contributors who might have an opinion on flag naming) who might want to weigh in/help us converge here? > 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. > Cool cool. > 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. > Perhaps - I think there are different use cases. A big one in LLVM we call -fstandalone-debug: Are you building everything with debug info, or only one or two files/can the compiler assume other files will be built with debug info. (this affects basically the same things as -femit-class-debug-always). Split DWARF for users with distributed build systems. Several options can weight object size compared to linked executable size - such as using base address selection entries in range and location lists (reducing relocations). Obviously I'm biased here - I live in this stuff & have users/use cases that are... not the norm. > 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), I imagine quite a few users build with optimization for particular CPUs - though, again, partly my bias of working on a homogenous/controlled environment in data centers, rather than trying to build a binary to send to random users in the world. But I'd guess games and things that want to eek out performance probably want to use modern CPU features if available. > 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. > Maybe. I'd guess a fair few users (especially in their continuous integration systems, etc) might have some different tradeoffs in terms of compile/link time and debugging/debugger startup time (indexes are a particularly potent example of this - pay some link time for some debugger startup improvement - but if I don't use a debugger very often, I may not want to pay that link time cost all the time). > 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=single using SHF_EXCLUDED for gcc and then make that the > default. > Yeah, we've got support for that model in Clang - but to be honest, one of the major motivations for implementing Split DWARF was Google's internal use (big distributed build system) & the split mode isn't a mistake in this context - not having to ship all the DWARF bytes to the machine doing the link is a significant savings. (even if we ship all those bytes to another machine to make a dwp) and smaller files to pull down when a user wants to debug from the dwo files - they pull down the executable, then as-needed, based on the index, pull down dwo files - if gsplit-dwarf=single was used, in addition to shipping the dwo bytes to the linker, you also re-ship the non-dwo bytes for any object file that needs to be pulled over the network for debugging, rather than only the dwo bytes. - David