davide added a comment. In https://reviews.llvm.org/D32167#1019621, @labath wrote:
> In https://reviews.llvm.org/D32167#1019504, @clayborg wrote: > > > In https://reviews.llvm.org/D32167#1019467, @labath wrote: > > > > > However, I am not so sure about the proliferation of debug info variants > > > that we seem to be having. Right now we have two outstanding patches > > > wanting to add a debug variant, which would bring the total amount of > > > variants per test to 6. I'm not sure this is a tractable way forward. > > > IIUC, clang only puts "non-trivial" types in type units. I'm not sure > > > how many of our tests even define classes/structs (i.e., for how many > > > tests this debug info variant would actually be testing something new). > > > > > > We could check after the build if the binary for the test even has a > > .debug_types sections and if not abort? That was we don't have to mark up > > the test in any way (like "this tests has structures or enums"), but we > > could ensure we test with .debug_types when needed. > > > That would help somewhat, but that's still a very "shotgun" approach to > testing this. What I would try to do (and I think this is what Davide had in > mind as well) is to identify the cases that are interesting from the type > unit perspective (a single class in type unit, two classes in type units > referencing each other, class referencing an enum, etc. (I'm not really sure > about what all that goes into a type unit)) and then write specific tests for > that (or reuse existing ones). For example, plenty of tests do breakpoint > setting or unwinding and those probably don't have to be tested separately > with type units (or maybe one test that checks that setting breakpoint on a > method in type unit is sufficient). Precisely. I'm afraid what's proposed here is too coarse to be useful. https://reviews.llvm.org/D32167 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
