<div dir="ltr">Hi Ted!<div><br></div><div>I hope you don't mind - I'm going to CC lldb-dev since there is some useful general info in here for others who are getting started with the test system.  (And others can fact-check anything I may gloss over here).</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 21, 2016 at 2:00 PM, Ted Woodward <span dir="ltr"><<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal">Hi Todd,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I’m working on getting the LLDB tests running with Hexagon, but I’m confused about some things. Here are my initial results:<u></u><u></u></p><p class="MsoNormal"><span style="font-family:'Courier New'">===================<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Test Result Summary<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">===================<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Test Methods:        967<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Reruns:                2<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Success:             290<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Expected Failure:     25<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Failure:              89<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Error:               111<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Exceptional Exit:     13<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Unexpected Success:    2<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Skip:                434<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Timeout:               3<u></u><u></u></span></p><p class="MsoNormal"><span style="font-family:'Courier New'">Expected Timeout:      0<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">First question – How can I tell what certain tests are doing?</p></div></div></blockquote><div><br></div><div>There are two places you can look for more information.  Of those categories that are counted, the following should list the specific tests that are failing in a section called something like "Test Details" directly above the "Test Result Summary" section:</div><div>* Failure</div><div>* Error</div><div>* Exceptional Exit</div><div>* Timeout</div><div><br></div><div>Those will tell you which test method names (and file path relative to the packages/Python/lldbsuite/test directory).  You should also get a stack trace above that section when it is counting out the tests that are running.</div><div><br></div><div>But, that's not really the heavy detail info.  The heavy details are in a "test session directory", which by default is created in the current directory when the test suite is kicked off, and has a name something like:</div><div><br></div><div>2016-01-21-15_14_26/</div><div><br></div><div>This is a date/time encoded directory with a bunch of files in it.  For each of the classes of failure above, you should have a file that beings with something like:</div><div><br></div><div>"Failure-"</div><div>"Error-"</div><div><br></div><div>(i.e. the status as the first part), followed by the test package/class/name/architecture, then followed by .log.  That file records build commands and any I/O from the process.  That is the best place to look when a test goes wrong.</div><div><br></div><div>Here is an example failure filename from a test suite run I did on OS X that failed recently:</div><div><br></div><div><div>Failure-TestPublicAPIHeaders.SBDirCheckerCase.test_sb_api_directory_dsym-x86_64-clang.log</div></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"> For example, TestExprPathSynthetic, from packages/Python/lldbsuite/test/python_api/exprpath_synthetic/TestExprPathSynthetic.py .<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">TestExprPathSynthetic.py has:<u></u><u></u></p><p class="MsoNormal">import lldbsuite.test.lldbinline as lldbinline<u></u><u></u></p><p class="MsoNormal">import lldbsuite.test.lldbtest as lldbtest<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">lldbinline.MakeInlineTest(__file__, globals(), [lldbtest.skipIfFreeBSD,lldbtest.<u></u><u></u></p><p class="MsoNormal">skipIfLinux,lldbtest.skipIfWindows])<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I’m going to want to add a skip in there for Hexagon, but what does this test actually do?</p></div></div></blockquote><div><br></div><div>I haven't worked directly, but in general, the MakeInlineTest tests are used to generate the python side of the test run logic, and assume there is a main.c/main.cpp/<a href="http://main.mm">main.mm</a> file in the directory (as there is in that one).  The main.* file will have comments with executable expressions in them that basically contain everything needed to drive the test using the compiled main.* file as the test inferior subject.</div><div><br></div><div>This particular test looks like it is attempting to test synthetic children in expression parsing for objective C++.  This one probably should say something like "skipUnlessDarwin" rather than manually adding all the other platforms that should skip. (Objective-C++ and Cocoa tests should only run on Darwin).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Second question – a lot of tests are skipped. Are the skipped tests always skipped because of something like @benchmarks_test being false, or @skipIfFreeBSD being true?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> </p></div></div></blockquote><div><br></div><div>Skipped tests are any test that is listed as @skipifXYZ, @unittest2.skip or the like.  Skips happen for a ton of reasons.  Most of our tests now get turned automagically into 3 or so tests - one for each type of debuginfo that a test inferior subject can be compiled as.  Those are:</div><div>* dsym-style debuginfo, only available on OS X</div><div>* dwarf (in-object-file dwarf, all platforms generally have this)</div><div>* dwo (only on Linux right now I think)</div><div><br></div><div>So each test method defined typically has three variants run, one created for each debuginfo type.  On any platform, only two (at most) typically run, the rest being listed as skipped.  A large number of skips will be due to that.  On non-Darwin platforms, a larger number will be skipped because they are OS X-specific, like Objective-C/Objective-C++.</div><div> </div><div>That test session directory will show you all the skipped ones.  They start with "SkippedTest-".</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Third question – I see things like this:<u></u><u></u></p><p class="MsoNormal">        self.build(dictionary=self.getBuildFlags())<u></u><u></u></p><p class="MsoNormal">(from packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py )<u></u><u></u></p><p class="MsoNormal">How do I see what the build flags are? How does it know which file to build?<u></u><u></u></p><p class="MsoNormal"><u></u> </p></div></div></blockquote><div> </div><div>The test session directory will have a separate log for each test method that is run.  It will show the build commands that were run.  In your case, I'd expect you have a --platform-name specified to "hexagon" or "hexagon-simulator" or something like that.  You'd want the build system to know about that platform, and "do the right thing" when building test inferior programs for it.  The test runner also supports a -C specifying the compiler to use and a -A to specify the architecture(s) to run.  But I think you want to rig things so that --platform-name {your-platform} works the way you need.</div><div><br></div><div>The build rules typically come from the Makefile in the test directory.  If you take a few of them and look, you'll see they include a set of rules from packages/Python/lldbsuite/test/make/Makefile.rules.  I'd expect you'd end up adding info in there for doing the right thing for the hexagon platforms.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Fourth question – IntegerTypesTestCase.test_unsigned_short_type_dwarf <u></u><u></u></p><p class="MsoNormal">I don’t see test_unsigned_short_type_dwarf, just test_unsigned_short_type<u></u><u></u></p><p class="MsoNormal">What does<u></u><u></u></p><p class="MsoNormal">    def test_unsigned_short_type(self):<u></u><u></u></p><p class="MsoNormal">        """Test that 'unsigned_short'-type variables are displayed correctly."""<u></u><u></u></p><p class="MsoNormal">        self.build_and_run('unsigned_short.cpp', set(['unsigned', 'short']))<u></u><u></u></p><p class="MsoNormal">actually do?<u></u><u></u></p><p class="MsoNormal"><u></u> </p></div></div></blockquote><div><br></div><div>That class derives from something called "GenericTester".  That class likely defines the build_and_run(), which looks like it assumes the output that gets printed for any given type via the test inferior with basic_type.cpp being the "test inferior driver" (i.e. the thing that prints all the type contents).  It looks like it is a templated style of test that runs against a bunch of different concrete types.  The AbstractBase.py class in that directory (packages/Python/lldbsuite/test/types) has some documentation that explains how it works.</div><div><br></div><div>I hope that gets you going!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">That’s it for now…before my brain melts! <span style="font-family:Wingdings">J</span><u></u><u></u></p><p class="MsoNormal"><u></u> </p></div></div></blockquote><div><br></div><div>:-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><p class="MsoNormal"><u></u></p><p class="MsoNormal">Thanks,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Ted<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><br></div></blockquote><div><br></div><div>My pleasure!</div><div><br></div><div>-Todd</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">--<u></u><u></u></p><p class="MsoNormal">Qualcomm Innovation Center, Inc.<u></u><u></u></p><p class="MsoNormal">The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div></div>