<div dir="ltr"><div dir="ltr">> 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).<div><br></div><div>Hi Davide and Mike,</div><div><br></div><div>I have received an email from <a href="mailto:llvm.greendragon@gmail.com">llvm.greendragon@gmail.com</a> about a broken job of lldb-xcode. This is definitely an improvement and I would like to thank you. (This time it seems it is not my commit which breaks the bot, it looks like this is a commit related to breakpad).</div><div><br></div><div>Cheers,</div><div>Gabor</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" target="_blank">dccitaliano@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></div></div></div>