<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Davide,<div><br></div><div>Thank you for your email.</div><div><br></div><div>> In particular, what's the error you get when lldb fails immediately running the tests?<br>> Also, have you checked libcxx and libcxx-abi in your build? We might<br>> consider making that a mandatory dependency for the Cmake build.<br></div><div><br></div><div>Finally I could run the test suite ("ninja check-lldb) on our macOS without errors. Here are my findings:</div><div>1) "sudo /usr/sbin/DevToolsSecurity --enable" is a must. </div><div>2) I indeed did not checked out libcxx. (libcxx-abi was not needed to have a successful run). Would be great to make that a mandatory dependency.</div><div>3) Besides that I recognized that "ninja check-lldb" target does not build all it's dependencies. E.g. lldb-server tests failed until I executed "ninja debugserver" before "ninja check-lldb". I am not sure, but I think "ninja obj2yaml" and "ninja llvm-pdbutil" are also prerequisites (and these targets seem not to be built by a simple "ninja" command).</div><div><br></div><div>Thanks,</div><div>Gabor</div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 1, 2018 at 9:40 PM Davide Italiano <<a href="mailto:dccitaliano@gmail.com">dccitaliano@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Dec 1, 2018 at 8:00 AM Gábor Márton via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Dear LLDB Developers,<br>
><br>
> There is an ongoing activity to improve ASTImporter in Clang to make it support<br>
> C++ (and C) completely and correctly.  Our team works on cross translation unit<br>
> (CTU) static analysis where we use the in-tree Clang static analyzer in<br>
> combination with the ASTImporter (via the scan-build.py script or CodeChecker).<br>
> In the past 18 months we have committed more than 70 patches to make the<br>
> ASTImporter better.  Our primary target is Linux and we do run the LLDB tests<br>
> on Linux before we commit.  Unfortunately, quite recently 3 of these patches<br>
> broke the LLDB macOS buildbots (<a href="http://green.lab.llvm.org/green/view/LLDB" rel="noreferrer" target="_blank">green.lab.llvm.org/green/view/LLDB</a>) and this<br>
> caused some turmoil.  We are very sorry about this and we are making actions to<br>
> avoid such inconveniences in the future: We ordered a Mac Mini, until it<br>
> arrives we are using a borrowed Mac Book. We are going to create a CI job which<br>
> will execute the macOS LLDB test suite for a specific patch. Besides this, for<br>
> every patch we are going to monitor the macOS buildbots once they are<br>
> committed.<br>
><br>
> However, we are experiencing problems both with the buildbots and with the LLDB<br>
> tests, therefore we are asking help from the LLDB community in the following:<br>
><br>
> (1) Apparently, the green lab macOS buildbots are not displayed in the build<br>
> bot console (<a href="http://lab.llvm.org:8011/console" rel="noreferrer" target="_blank">http://lab.llvm.org:8011/console</a>). More importantly they are not<br>
> capable of sending emails to the authors of the commit in case of failure.<br>
> Would it be possible to setup the these buildbots to send out the emails for<br>
> the authors?<br>
><br>
<br>
Thanks for reporting this problem. I cc:ed Mike, as he owns the bots,<br>
and he should be able to help us with this.<br>
(I do have access to the Jenkins configuration but I don't feel<br>
confident enough to make the change myself).<br>
<br>
> (2) We are facing difficulties with the LLDB lit tests both on macOS and on<br>
> Linux. E.g. on a fresh macOS mojave install, checking out master LLVM, Clang,<br>
> LLDB and then executing ninja check-lldb fails immediately.  On Linux we<br>
> experienced that some tests fail because they try to read a non-existent<br>
> register. Some tests fail non-deterministically because they can't kill a<br>
> process or a timeout is not long enough. Some tests fail because of a linker<br>
> error of libcxx. We would like to address all these issues. Would you like to<br>
> discuss these issues on lldb-dev or should we create a bugzilla ticket for<br>
> each?<br>
><br>
<br>
I think either of them is fine. If you're willing to spend some time<br>
on this, I'm sure people on the LLDB side will consider helping you.<br>
In particular, what's the error you get when lldb fails immediately<br>
running the tests?<br>
Also, have you checked libcxx and libcxx-abi in your build? We might<br>
consider making that a mandatory dependency for the Cmake build.<br>
<br>
> (3) ASTImporter unit tests and lit tests in Clang for the LLDB specific usage<br>
> are very-very limited.  LLDB uses the so called "minimal" import, but none of<br>
> the unit tests exercises that (CTU uses the full import).  We should have a<br>
> unit test suite where the LLDB use cases are covered, e.g. after a minimal<br>
> import an `importDefinition` is called. Also, a test double which implements<br>
> the ExternalASTSource could be used.  I believe it would be possible to cover<br>
> with the unit tests all LLDB/macOS related scenarios and these tests could run<br>
> on Linux too.  We do something similar in case of windows: we execute all unit<br>
> tests with "-fdelayed-template-parsing" and with "-fms-compatibility" too. I<br>
> think, the more unit tests we have in Clang the sooner we catch the LLDB<br>
> specific importer errors.  I am asking the LLDB community's help here, because<br>
> we lack the domain knowledge in LLDB so we don't know what expectations should<br>
> we write in each unit test cases.  (About lit tests, there is clang-import-test<br>
> but its coverage seems pretty low and I don't know if that really exercises all<br>
> LLDB use cases.)<br>
><br>
<br>
Definitely. +1.<br>
<br>
--<br>
Davide<br>
</blockquote></div>