jmorse added a comment.

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.


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

Reply via email to