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. 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. 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=single using SHF_EXCLUDED for gcc and then make that the default. Cheers, Mark
