On 30 November 2017 at 19:10, Zachary Turner via Phabricator <revi...@reviews.llvm.org> wrote: > zturner added a comment. > > In https://reviews.llvm.org/D40475#935615, @labath wrote: > >> The thing to be aware of with this testing strategy is that you will >> probably be the only person who will be able to run these tests and verify >> dwz functionality. If you don't setup a buildbot testing this then other >> developers will never even know if they have broken any dwz functionality in >> the future. While end-to-end tests are great and we need them, I think it >> would be worthwhile to think about other testing strategies. These can range >> from checking in a couple of siple dwz files and making sure we can extract >> information from them (see unittests/SymbolFile/PDB for code that does >> something similar) to reimplementing/upstreaming the utilities necessary to >> build dwz files ourselves (I am not sure what the `dwz` tool does, but the >> `eu-strip` and `sepdebugcrcfix` tools sound like they would be fairly easy >> to implement on top of existing llvm libraries). >> >> The other thing that worries me is that your comments seem to indicate that >> not all dwz tests pass after this. Could you elaborate on the "Many ERRORs >> are correct" part and how you plan to rectify that? >> >> The third thing I want to say is not really related to your patchset, but >> your comments seem to indicate that not all regular dwarf tests were passing >> for you to begin with. Is that true? Would you be willing to help me >> (probably in a separate thread) to identify the tests that are failing and >> why? I'd like to move us towards a state where the result of the tests does >> not depend on the system you're running on and people don't have to resort >> to differential comparisons. > > > With the forthcoming introduction of `lldb-test`, why don't we piggyback off > of that? We already have a compiler, so use it to produce a `dwz`, and then > use `lldb-test` to exercise something about it. It won't be as comprehensive > as a full scale test, but it would be a nice complement. We'd have basic > test coverage on all platforms right out of the gate.
The trick here is that no compiler produces "dwz" out of the box. The trick here that you have to pipe the compiler output through this dwz tool, which seems to be an unmaintained 10K-line blob of C code. However, what we could do is use the dwarf<->yaml conversion tool that Greg worked on to synthesize some "interesting" dwz, and then use lldb-test to make sure we can parse it and extract some reasonable information out of it. _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
