Re: [patch] [gdb/testsuite] include a use of the definition of a type to cause clang to emit debug info

[Joel Brobecker <brobecker@adacore.com>]

> Minor (but important) correction: this isn't introducing a typedef,
> it's introducing a variable.

OK - sorry for the confusion - I went too fast and it changes
the perspective a little.

> This comes into a discussion about whether the GDB test suite is a
> test suite for GCC (or Clang) or for GDB. I'm by no means in a
> position to make a claim as to which of these things it is, though
> it's clear that GCC and Clang use this suite to validate their
> behavior relative to GDB.

I don't remember if this was ever discussed, but it should be
compiler-neutral, IMO, even if we do have a practical bias towards
GCC. The intent is to test that, with the compiler you have, GDB
is able to debug your code as expected.

> But it'd probably be nice to separate out those things a little

We try to do it, sometimes. That's why we have gdb.dwarf2.
Ideally, for every testcase, we'd create one using assembly
sources to control exactly the code/debug-info produce, and
one where we compile some source which, at some point, resulted
in the assembly we used in our first testcase. That way, we test
both the handling of that particular output, as well as the
user-level handling of whatever gets generated by your compiler.
But it is a lot of work, and sadly, usually only one of the two
options is elected when new testcases are added. Just a practical
matter.

> I've tried to be consistent to this principle with the patches I'm
> providing - if there's a difference in Clang and GCC behavior that's
> not necessary for a test case to test GDB and the test can be adjusted
> to be neutral to that difference, I've tried to change the tests in
> that direction.

My position, in this situation, is that your change is actually
not completely neutral: Even if this was not the initial intention
when the test was written, as it is now, it allows us to verify
that the compiler produces the full debugging information for
an enum type even in the case where the type is only referenced
through a pointer. By adding a global variable, we lose that part,
potentially allowing GCC to regress (from a GDB user's perspective).

If the type was opaque, I would have had no objection. But in this
case, I try to put myself in the shoes of a user debugging that code,
and it would seem reasonable to be able to dereference "e".

-- 
Joel