[llvm-dev] Status of debuginfo-tests

Adrian Prantl via llvm-dev
Thu, 07 Sep 2017 19:19:52 -0000

> On Sep 7, 2017, at 12:11 PM, Adrian Prantl <aprantl at apple.com>
wrote:
>
>>
>> On Sep 7, 2017, at 12:01 PM, Zachary Turner <zturner at google.com
<mailto:zturner at google.com>> wrote:
>>
>>
>>
>> On Thu, Sep 7, 2017 at 11:49 AM Adrian Prantl <aprantl at apple.com
<mailto:aprantl at apple.com>> wrote:
>>> On Sep 7, 2017, at 11:37 AM, Zachary Turner via llvm-dev
<llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
wrote:
>>>
>>> To be clear, the tests I'm proposing will have no resemblance
whatsoever to GDB, so I would be intentionally forking the set of tests in this
regards.  So there would very clearly be a paradigm shift in writing CodeView
debug info tests (which would be written in JavaScript using WinDbg specific
debugger commands) and DWARF debug info tests (which would be written in
whatever / using GDB style commands)
>>
>> That sounds like an unfortunate direction. Can you explain why it
wouldn't be possible to write a wrapper (in JavaScript) that interprets the
3ish gdb commands used by the tests in terms of WinDbg? Similar to how LLDB is
supported?
>>
>>
>> I can think of a couple of reasons:
>>
>> 1) We're already going to need entirely different runlines.  clang
and clang-cl don't use the same command line options, or for that matter
even styles.
>
> I'm not familiar with clang-cl so please bear with me if this is a
stupid question: Is clang-cl just an MSVC compatible driver? Can you not produce
the same result by using the "standard" clang driver and a windows
target triple?
>
>>
>> 2) The output format is going to be different.  whereas the current
tests look for things like
>
> If you are going to write a wrapper script for the debugger commands, that
wrapper script could also transform the output to look more like the GDB output
that the CHECK-lines are looking for.
>>
>> // CHECK: ${{[0-9]+}} >> // CHECK:  Data ={{.*}} 0x0{{(0*)}}
>> // CHECK:  Kind = 2142
>>
>> In WinDbg this is going to be more like:
>>
>> Local var @ 0x6ffa50 Type SVal
>>    +0x000 Data             : (null)
>>    +0x004 Kind             : 0x85e
>>

Alternatively, this is still similar enough that we could relax the check to
look like
  CHECK: Data{{.*[:=].*(0x0|.null.)}}
  CHECK: Kind{{.*[:=].*(2142|0x85e)}}
without much loss.

-- adrian
>> So we're also going to need different check lines.
>> At this point, the only similarities in the PDB / DWARF tests is going
to be the source code, as I don't see an easy way to automatically translate
command lines, input commands, and output text.
> By the way, I'm fine with adding, e.g., a PDB subdirectory with a lit
filter that contains tests that will only work under Windows, but it would be
very unfortunate if there was no common set of tests, since then the Windows
folks wouldn't benefit from new tests being added for GDB and vice versa.
>
> -- adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170907/080c5c93/attachment.html>