[cfe-dev] Create a clang/test/DebugInfo directory?

[Robinson, Paul]

From: Eric Christopher [echristo at apple.com]
>On Jun 5, 2012, at 5:09 PM, "Robinson, Paul" <Paul.Robinson at am.sony.com> wrote:
>
> > I've noticed that debug info tests for LLVM tend to land in llvm/test/DebugInfo, while tests on the Clang side typically end up in one of the clang/test/CodeGen* directories.  I suggest that Clang's debug info tests go into their own clang/test/DebugInfo directory.
> > I do see that LLVM has a lib/DebugInfo and Clang does not, and the test directories are sort-of parallel to the lib directories.  But still, debug info isn't _really_ CodeGen, and if you want to focus on debug info, it would be easier to see what's already there if they were all in one place instead of scattered across various test/CodeGen* directories.
>
> I'd just kept the existing ones as a way of segregating the debug info by language, but I'm not wedded to it. If another organization makes more sense to people we can go ahead and move some files around :)
>
> What'd you want to do about language stuff? or just let the file suffix be the description?
>
> -eric

If the goal is a set of tiny patch-specific regression tests, then it
probably makes more sense to associate each one with the module where
the patch went; this is what we have today.

If the goal is to build a collection of tests for the overall debug-info
feature, then it makes more sense to keep them together in one place,
regardless of language. A lot of the debug info is language-agnostic,
and the choice of implementation language for the test is frequently
arbitrary. (Not always true, of course.) And file suffix should be
enough to distinguish one language from another, sure; particularly 
since we have one compiler able to accept all of them. (This was not so
true in my previous job where we had 3 very different compilers to work
with.)

Having all the debug info tests in one place makes it a lot easier to
see what there is, and more importantly what's missing, from the 
perspective of overall debug-info coverage and quality. It also might
help motivate some specialized tools, beyond llvm-dwarfdump and FileCheck,
for analyzing particular kinds of problems.  For example in a previous
job I had a tool that let me compare two object files (compiled from the
same source at -O0 and -O1, usually) and verify that the line tables had
the is_stmt flag set for the same set of lines. This was important to our
goal of having a very nice -O1 debugging experience.

While users running code under the debugger are the final judges, trying
to automate that in a test suite places a lot of restrictions on what you
can do. First off, you have to have your target and host platforms be the
same, and then you have to have the right debugger running on that host.
Just look at how many of the tests in debuginfo-tests have an XFAIL in 
them--over half. This is why I'd prefer to keep as much of the testing
as possible within Clang and LLVM, where cross-platform testing is easy.

Well, that was more answer than you asked for. :-) But that's most of my
thinking about organizing the debug-info stuff.
Thanks,
--paulr