[Lldb-commits] [PATCH] D106084: [DebugInfo] Switch to using constructor homing (-debug-info-kind=constructor) by default when debug info is enabled

Thu Jul 22 12:38:28 PDT 2021

dblaikie added a comment.

In D106084#2897515 <https://reviews.llvm.org/D106084#2897515>, @jmorse wrote:

> David wrote:
>
>> think what I'm missing here: If -fno-standalone-debug is already in use/the default and is causing missing types because parts of the program are bulit without debug info, then I'm not sure what the rationale is for slicing -fstandalone-debug into a "has ctor homing" and a "doesn't have ctor homing" strategy. The same general design philosophy applies - that in both cases (about 4 cases in total now: types that aren't required to be complete, explicitly instantiated templates, vtables, and now ctor homing) the whole program must be compiled with debug info enabled for these DWARF size optimizations to be sound.
>
> It's a matter of degree:
>
> - Some types go missing, but due to the dllimport mechanism mentioned, all the important ones are retained,
> - Switching to -fstandalone-debug increases the amount of DWARF by ~50% in experiments I've run, which for a {single-file-recompile, link, load-into-debugger} round trip will translate to an almost 50% increase in round-trip-time. (What with DWARF being the major part of linking and debugger-loading).
>
> Thus the status quo (-fno-standalone-debug and closed-source libraries) hasn't been conceptually sounds, but it's given a "good enough" debugging experience without major round-trip-time penalty.

I think it'd be unfortunate to split this hair in LLVM/Clang proper & feel like that sort of value tradeoff might be better suited in a downstream patch. (mostly because eventually it'd be good to get rid of the distinction between other type homing and ctor type homing entirely - there's already 3 categories of type homing under the existing category (type completeness, explicit template instantiations, and vtable based homing) & I don't think there's a good line to draw between those and ctor type homing - and module type homing (which I think I've already implemented &the  is under -fno-standalone-debug, but no one's using modular code generation right now so it's not super interesting to anyone), maybe ThinLTO type homing (which would be a bit more robust than the others, since it has whole program-ish view)

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106084/new/

https://reviews.llvm.org/D106084