dblaikie added a comment. In D80391#2497073 <https://reviews.llvm.org/D80391#2497073>, @MaskRay wrote:
> From @dblaikie's email reply: > >> ^ this I would consider to be a bug. -g should be needed to generate debug >> info into the IR, and -gsplit-dwarf should be needed to choose how debug >> info already in the IR should be placed into object files or dwo files. >> >> Usually (non-LTO) these two steps are in the same compile, so -g and >> -gsplit-dwarf go together. But for LTO cases, I think it's suitable for -g >> to be needed for IR generation, and -gsplit-dwarf to be needed for object >> code generation, without needing -g as well in that latter step (the -g was >> already specified at IR generation time, and that shoul be enough). >> >> We can see that behavior I'm describing as desirable in implicit ThinLTO I >> showed earlier in the thread. >> >> I suggest this should be the desired behavior, because -g generally has no >> effect on IR->object code generation, so it seems strange/unnecessary to me >> to gate -gsplit-dwarf behind -g in that case. The -g was already specified >> and used during IR generation (& the -gN level, -gmlt behavior-etc has all >> been handled in IR generation (or embedded in the IR for use later) - so to >> me, specifying -g again during object code generation would be/is strange, >> because any special values would be ignored (-g1/g2/g3/etc would not be >> respected - the N value would only be respected when passed to the IR >> generation step)) > > Got it. `-fthinlto-index=` (thinlto backend compile) operates on bitcode > files and does not IR generation. It isn't suitable for `-g` to be needed to > use. > -gsplit-dwarf is both an IR generation option and an object file generation > option. It is needed for thinlto backend compiles. (sounds like we're mostly on the same page now - minor note though: I don't think -gsplit-dwarf is an IR generation option. I don't think it has any effect on IR generation - I believe the IR is exactly the same whether it ends up being used with split or unsplit DWARF generation) > In Bazel, I think a typical configuration's `LTO Backend Compile` includes > almost every option in the initial compile, so I did not notice the issue. I > am working on a patch. Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80391/new/ https://reviews.llvm.org/D80391 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
