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

Amy Huang via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Jul 22 12:25:28 PDT 2021

akhuang 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.

Right, I think chromium on mac does the same thing (build with -fno-standalone-debug even though it drops some types, because -fstandalone-debug is too large).

  rG LLVM Github Monorepo



More information about the lldb-commits mailing list