clayborg added a comment. In https://reviews.llvm.org/D32167#1019701, @labath wrote:
> In https://reviews.llvm.org/D32167#1019635, @jingham wrote: > > > Note, I have (though very very occasionally) seen a dsymutil bug that broke > > line tables. So it would be good to keep a few "set a breakpoint and run > > to it" tests just to sanity check this. But most tests that just run > > somewhere and print a backtrace or view an integer variable or such-like do > > not need to run all variants. > > > The thing here is that I'm not sure everything can be captured by a single > "debug info variant" dimension. The current dimensions kinda make sense, as > in they alter the way pretty much all of debug info is accessed (we can think > of "dwarf" as the basic one, "dsym" and "dwo" are similar in that they place > everything in a separate file, I'm not sure about gmodules, but that's > because I have no idea on how it works). However, I'm not sure the same goes > for type units. For one they are not completely mutually exclusive with the > existing variants, so you can have type-units+regular dwarf and type > units+dwo (maybe even type units+dsym?). But obviously we can't add another > "type unit" dimension and do a cartesian product.... if you see how horrible type units are in their implementation, you might change your mind. If one has a positive view of type units, you might think "I get one type and one type only and that can only mean good things". I reality this feature's implementation is really messy and there are so many areas that can screw up. For instance if you have a class that has static members, you will get a nice full type in the type unit that defines everything in the class. But with type units you can't refer to anything within the type unit itself other than the top level type itself (the struct/union/class or enum). So you now need to declare a DW_TAG_variable that points to the static member of the class so you can give it an address... What happens? The type is duplicated in each compile unit that uses it and a skeleton incomplete version of the class is represented in the compile unit DWARF (not in a type unit). The top level DW_TAG_structure or DW_TAG_class has a DW_AT_signature that points to the type in the type unit, but the incomplete struct/class has _just_ the static members inside of it (again, in the compile unit, not in the type unit). Then you have a DW_TAG_variable that points to the DW_TAG_member within the incomplete struct or class because there is no way to point to anything within the type if the type is in a type unit. So I believe that we do need to fully test types and run the .debug_types as a separate variant. Each compiler might also do things a bit differently as there is nothing in the .debug_types specification that says that this is how things need to be. And that is just one thing I found while debugging .debug_types... I am sure there are more skeletons in the closet. If we want to support this feature we need to test it. I come to this conclusion after years of dealing with many different "this DWARF does this cool new way to do things" where it has bit us in the past and things break. https://reviews.llvm.org/D32167 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
