[llvm-dev] Status of debuginfo-tests

Zachary Turner via llvm-dev
Thu, 07 Sep 2017 19:31:32 -0000

That's true, but it still requires the person writing the test to be
familiar with both formats. Also anything more trivial than dumping a
single local variable will probably run into even more issues.

For example, The expression parsers each have their own unique quirks, and
it might not always be easy to translate.

Besides all the format compatibility issues, there's the more general issue
that massaging one format into another format just introduces another place
for things to go wrong and/or be flaky. But as we are the ones that have to
do the massaging, we get the short end of the stick.

One possible bridge is to make some sort of special directive that
identifies a certain fragment of the test file as gcc input & checks, and
another directive that identifies windbg input & checks.

This way each could have their own native run lines, debugger commands, and
check statements, but share the same source code. The runner then chooses
which mode to run based on which directives are present and whether a
debugger to run the corresponding fragment in is found.

This way you could have one or both directives in a file, and we'd run
whichever version(s) are appropriate
On Thu, Sep 7, 2017 at 12:19 PM Adrian Prantl <aprantl at apple.com>
wrote:

> 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>
wrote:
>
>
>
> On Thu, Sep 7, 2017 at 11:49 AM Adrian Prantl <aprantl at apple.com>
wrote:
>
>> On Sep 7, 2017, at 11:37 AM, Zachary Turner via llvm-dev <
>> 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/71fa55b0/attachment.html>