labath added a comment. 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). https://reviews.llvm.org/D32167 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
