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).
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D106084/new/
https://reviews.llvm.org/D106084
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
