[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

Fri Aug 19 06:05:40 PDT 2022

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