dblaikie added a comment. In D69822#1733262 <https://reviews.llvm.org/D69822#1733262>, @probinson wrote:
> In D69822#1733243 <https://reviews.llvm.org/D69822#1733243>, @dblaikie wrote: > > > In D69822#1733226 <https://reviews.llvm.org/D69822#1733226>, @probinson > > wrote: > > > > > > Want to decouple setting the DWARF version from enabling/disabling > > > > generation of debug info. > > > > > > Um, why? > > > > > > If you've got a big build system with various users opting in/out of DWARF > > and you want to migrate to DWARFv5, say, but you can't add "-gdwarf-5" to > > your build system, because that'd turn on debug info in cases that don't > > need it - but it's easier to change the default than to modify all cases > > that enable dwarf across the codebase. > > > > Open to discussion about whether this is a good/bad idea - but it'd be > > useful for Google at least & seemed low-cost enough to go this route. > > > Because you want the default to be based on your corporate environment rather > than the target platform. Sure - if we know our users have access to a modern debugger, but we don't own a whole platform. You could imagine someone shipping clang+debugger in a 3rd party/non-platform IDE might want something like this too/similar to the Google situation. We can't dictate what's suitable for all of Linux, but for the subset of users that are using a specific toolchain/situation, we can. > The maze of twisty -g passages gets a new secret door. Oh well. If you find this to be a significant complication, I'd really like to discuss it further - I know there are some twisty things (one of the worst I created when it comes to -fsplit-dwarf-inlining, -gsplit-dwarf, -gmlt combinations) - but this seems pretty simple/tidy/orthogonal to me. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69822/new/ https://reviews.llvm.org/D69822 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
