On Wed, Sep 2, 2020 at 4:12 AM Mark Wielaard <m...@klomp.org> 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 -f<debug-option>s not imply -g and having > any of the -g<debug-option>s 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
