On Wed, Feb 7, 2018 at 7:57 AM, Pavel Labath <lab...@google.com> wrote: > On 7 February 2018 at 14:20, Zachary Turner <ztur...@google.com> wrote: >> >> As someone who gave up on trying to set up a bot due to flakiness, I have a >> different experience. > > I did not say it was easy to get to the present point, and I am > certain that the situation is much harder on windows. But I believe > this is due to reasons not related to the test runner (such various > posixism spread out over the codebase and the fact that windows uses a > completely different (i.e. lest tested) code path for debugging). > > FWIW, we also have a windows bot running remote tests targetting > android. It's not as stable as the one hosted on linux, but most of > the issues I've seen there also do not point towards dotest. > >> Rust is based on llvm so we have the tools necessary for that. The rest are >> still maybe and someday so we can cross that bridge when (if) we come to it > > I don't know enough about Rust to say whether that is true. If it uses > llvm as a backend then I guess we could check-in some rust-generated > IR to serve as a test case (but we still figure out what exactly to do > with it). > > However, I would assert that even for C family languages a more > low-level approach than "$CC -g" for generating debug info would be > useful. People generally will not have their compiler and debugger > versions in sync, so we need tests that check we handle debug info > produced by older versions of clang (or gcc for that matter). And > then, there are the tests to make sure we handle "almost valid" debug > info gracefully...
This last category is really interesting (and, unfortunately, given our current testing strategy, almost entirely untested). 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. 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). -- Davide
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev