labath added a comment. In D131437#3710203 <https://reviews.llvm.org/D131437#3710203>, @clayborg wrote:
> In D131437#3709921 <https://reviews.llvm.org/D131437#3709921>, @labath wrote: > >> Seems reasonable, but could use a test case, though I'm not sure what would >> be the best way to approach that. I suppose one could dump the index of one >> of these dwo-less files, and then make sure it's contents are right (empty?). > > That is what I was struggling with. I might be able to use lldb-test to dump > a type lookup on a name that used to appear in both the DWO file and in the > skeleton compile unit and make sure no error string from the parsing gets > emitted? I haven't used lldb-test much, but is this possible to expect output > and make sure the error that detected this issue is not emitted once it is > fixed? The test would create a binary with -fsplit-dwarf-inlining enabled and > make sure that the skeleton compile unit ends up having a type from a type > template that _could_ be found if this fix wasn't there, then make sure when > we do a type lookup we don't see the error message. Let me know if you have > any other ideas on how to do this. Yeah, that's pretty much what I had in mind. I think it should be sufficient to run `lldb-test symbols` on this binary. Among other things, that will dump the contents of the dwarf index, and we can verify that it is empty. A good way to that is to use CHECK/CHECK-NEXT/EMPTY to match the lines before after the place where the output should appear. So, something like this might work: # CHECK: Function basenames: ## if the next line is empty then no entries have been printed # CHECK-EMPTY: Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131437/new/ https://reviews.llvm.org/D131437 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
