<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">we have some good coverage there that our PDBs are "as good as" Microsoft PDBs, and in the future we have plans to have a debug info test suite that tests LLD-generated PDBs with Microsoft debuggers.</span><br></blockquote><div><br></div><div>Thanks Zach. What I was asking is exactly the other half of this equation. Testing LLDB with MSVC produced PDBs should be complementary and I doubt we can get full coverage by just testing from the other direction (it's plausible that even with equivalent semantic information, certain patterns may only occur in MSVC produced debug information)</div><div><br></div><div>IMO reliable support for MSVC generated binaries and debug information is critical since even with a LLVM/LLD toolchain you'll still have system/3rd party modules, right?</div><div><br></div><div>Anyway, I was curious if any of this is in scope for Pavel's proposal and the answer seems to be no, thanks everyone.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 19, 2018 at 10:44 AM, Pavel Labath <span dir="ltr"><<a href="mailto:labath@google.com" target="_blank">labath@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 19 Apr 2018 at 18:19, Leonard Mosescu <<a href="mailto:mosescu@google.com">mosescu@google.com</a>> wrote:<br>
<br>
>>    the PDB tests under lit/SymbolFile/PDB need a linker to produce the<br>
program database<br>
<br>
<br>
> With this proposal, would we preserve any coverage for MSVC produced<br>
debug information?<br>
<br>
<br>
</span>Well.. the question there is what are you trying to test? Is it the fact<br>
your debugger works with a particular compiler+linker<br>
combination (note that those tests already compile with clang-cl), or that<br>
your pdb-parsing code is sane. (integration vs. regression test).<br>
<br>
Historically we've only had the former kind of tests (dotest), and we've<br>
had the ability (and used it) to run those tests against different kinds of<br>
compilers. This is all nice, but it means that a specific test will be<br>
testing a different thing for every person who runs it. That's why I would<br>
like to build up a suite of more regression-like tests (*). I would say<br>
that the tests under lit/*** should be regression tests and our goal should<br>
be to remove as many system dependencies as possible, and leave the job of<br>
testing integration with a specific toolchain to "dotest" tests (**).<br>
<br>
Technically, the answer to your question is "no", because currently dotest<br>
tests don't know how to work with cl+link. Making that work would be an<br>
interesting project (although a bit annoying as the Makefiles are full of<br>
gcc-isms). However, I don't think that should stop us here.<br>
<br>
(*) Ideally I would like to leave even the compiler out of the equation for<br>
these tests, and make it so that the tests always run on the exact same set<br>
of bytes. I am hoping I will be able to write at least some tests using .s<br>
files. However, I don't think I will do that for all of them, because these<br>
files can be long/verbose/tedious to write.<br>
<br>
(**) However, even "dotest" tests should have a "default" mode which is as<br>
hermetic as possible.<br>
</blockquote></div><br></div>