[lldb-dev] [RFC] Testsuite in lldb & possible future directions

[Davide Italiano via lldb-dev]

On Wed, Feb 7, 2018 at 7:57 AM, Pavel Labath <labath at google.com> wrote:
> On 7 February 2018 at 14:20, Zachary Turner <zturner at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180207/e44a478d/attachment.html>