dblaikie added a comment. In D106084#2890469 <https://reviews.llvm.org/D106084#2890469>, @probinson wrote:
>> (hence the renaming of "limited" a long time ago to "standalone-debug" to >> create a policy/philosophy around what goes in each category). > > Sorry, what? I thought -fstandalone-debug meant FullDebugInfo, and AFAICT > that's still how the driver handles it? Sorry, misspoke. -flimit-debug-info is -fno-standalone-debug. I meant the terminology changed, not the semantics - the terminology of "standalone" V "non-standalone" is the one that gives, in my opinion, the correct framing for when you would use one flag or the other. The core assumption of -fno-standalone-debug is that you've compiled the whole program with debug info enabled, so assumptions can be made about type debug info being carried by some other object file. If parts of the program (for instance, only one shared library has debug info and it interacts with others that don't) are built without debug info, then -fstandalone-debug is the right option to use. In D106084#2890823 <https://reviews.llvm.org/D106084#2890823>, @jmorse wrote: > In D106084#2890541 <https://reviews.llvm.org/D106084#2890541>, @probinson > wrote: > >> @jmorse am I remembering correctly, that we require dllimport-style >> annotations, so "limited" actually includes these types even if they aren't >> constructed locally? I am vague on the details here. But if ctor homing >> and limited both will consider a dllimport-ed type as requiring a full >> description, that's not a reason to pick one over the other. > > For anything shared between modules, indeed it needs the annotations (we try > to follow Windows here). I believe there can still be un-exported types from > the other modules headers that qualify for inclusion under "Limited" mode but > won't for "Constructor", and that's the benefit of Constructor mode / price > if the other module isn't built with debug-info. I 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. Is there some set of cases where the current set of homing strategies is sound, but ctor homing is not sound? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D106084/new/ https://reviews.llvm.org/D106084 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
