kwk added a comment. This looks good overall. I would add a section describing which test suite to use when you're interested in a particular DWARF feature for example. I heard from my GDB colleagues that the don't use a compiler, because that might change and produce a different DWARF. Instead they use a DWARF assembler (IIRC). I guess the analogy to LLDB would be yaml2obj which I see not mentioned here. Does it make sense to at least reference it in a section?
I forgot to mention that I'd love to have this at hand when I began developing for LLDB. So thank you very much for writing this up!!! ================ Comment at: lldb/docs/resources/test.rst:86 + +API tests are located under ``lldb/test/API``. Thy are run with the +``dotest.py``. Tests are written in Python and test binaries (inferiors) are ---------------- s/Thy/They ================ Comment at: lldb/docs/resources/test.rst:88 +``dotest.py``. Tests are written in Python and test binaries (inferiors) are +compiled with Make. The majority of API tests are end-to-end tests that compile +programs from source, run them, and debug the processes. ---------------- I personally struggled with the way inferiors are being build. The Makefile includes another Makefile and was more like a framework than simple make. You had to set special variables in order for the included Makefile to pick it up. That level of indirection made it quite complicated for me to get what I wanted. To put it differently, it would be nice if you could describe what the Makefile should look like or what is expected. ================ Comment at: lldb/docs/resources/test.rst:94 +The test directory will always contain a python file, starting with ``Test``. +Most of the tests are structured as a binary begin debugged, so there will be +one or more sources file and a Makefile. ---------------- s/begin/being ================ Comment at: lldb/docs/resources/test.rst:95 +Most of the tests are structured as a binary begin debugged, so there will be +one or more sources file and a Makefile. ---------------- s/sources/source s/file/files ================ Comment at: lldb/docs/resources/test.rst:122 + +It's possible to skip or XFAIL tests using decorators. You'll see them a lot. +The debugger can be sensitive to things like the architecture, the host and ---------------- Maybe link XFAIL to https://ftp.gnu.org/old-gnu/Manuals/dejagnu-1.3/html_node/dejagnu_6.html ? ================ Comment at: lldb/docs/resources/test.rst:142 +building inferiors. Every test has its own Makefile, most of them only a few +lines long. A shared Makefile (``Makefile.rules``) with about a thousand lines +of rules takes care of most if not all of the boiler plate, while individual ---------------- Ah, there you're mentioning it. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78242/new/ https://reviews.llvm.org/D78242 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
