<div dir="ltr"><br><br>On Wed, Feb 7, 2018 at 7:57 AM, Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a>> wrote:<br>> On 7 February 2018 at 14:20, Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br>>><br>>> As someone who gave up on trying to set up a bot due to flakiness, I have a<br>>> different experience.<br>><br>> I did not say it was easy to get to the present point, and I am<br>> certain that the situation is much harder on windows. But I believe<br>> this is due to reasons not related to the test runner (such various<br>> posixism spread out over the codebase and the fact that windows uses a<br>> completely different (i.e. lest tested) code path for debugging).<br>><br>> FWIW, we also have a windows bot running remote tests targetting<br>> android. It's not as stable as the one hosted on linux, but most of<br>> the issues I've seen there also do not point towards dotest.<br>><br>>> Rust is based on llvm so we have the tools necessary for that.  The rest are<br>>> still maybe and someday so we can cross that bridge when (if) we come to it<br>><br>> I don't know enough about Rust to say whether that is true. If it uses<br>> llvm as a backend then I guess we could check-in some rust-generated<br>> IR to serve as a test case (but we still figure out what exactly to do<br>> with it).<br>><br>> However, I would assert that even for C family languages a more<br>> low-level approach than "$CC -g" for generating debug info would be<br>> useful. People generally will not have their compiler and debugger<br>> versions in sync, so we need tests that check we handle debug info<br>> produced by older versions of clang (or gcc for that matter). And<br>> then, there are the tests to make sure we handle "almost valid" debug<br>> info gracefully...<br><br><div>This last category is really interesting (and, unfortunately, given our current testing strategy, almost entirely untested).</div><div>I think the proper thing here is that of having tooling that generates broken debug info, as yaml2obj can generate broken object files, and test with them.</div><div>lldb does a great deal of work trying to "recover" with a lot of heuristics in case debug info are wrong but not that off. In order to have better control of this codepath, we need to have a better testing for this case, otherwise this will break (and we'll be forced to remove the codepath entirely).</div><div><br></div><div>--</div><div>Davide</div></div>