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

[David Blaikie <dblaikie at gmail dot com>]

On Mon, Apr 14, 2014 at 11:16 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> > The gdb11479.exp is obvious and can be pushed. The change to gdb11479.c,
>> > on the other hand, changes the test, and I don't think we want that,
>> > because I disagree with the outcome of Clang's optimization here.
>> > If Clang doesn't want to fix the problem, best to just xfail the test
>> > with Clang, and write a new one that provides the type definition as
>> > Clang wants it.
>>
>> Could you describe your objection here? In particular, as it relates
>> to Dave's analysis of a similar gcc optimization. (Also a few people
>> have been interested in implementing this same behavior in gcc).
>
> The fact is, at the moment, that GCC generates the necessary debugging
> information, without the need to create a typedef.

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

> If it stops working
> thanks to a GCC "optimization", I would like to know about it (personally).

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.

But it'd probably be nice to separate out those things a little - this
test case isn't intended to test that GCC behavior. I believe/assume
this test case could still test the GDB behavior that it was committed
to validate without tickling the difference between GCC and Clang.

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.

In cases where a GCC or Clang output makes it impossible to test a GDB
feature (eg: "compiler X produces this quirky output that GDB should
handle nicely") I've either XFAILed the test if the difference is a
bug in the other compiler or adjusted the test to mark as UNSUPPORTED
when run under the other compiler ("hey, we can't produce that quirky
output on this compiler so in this configuration we can't test that
GDB can cope with it")

It's a bit fuzzy - I've XFAILed some thing that are bugs in one
compiler or the other even when the test case might be able to be made
agnostic to the difference because it took less time than refactoring
the test, and hey "it's a bug anyway".

> In this particular case, the type is used locally, albeit as a pointer,
> and it would seem unfriendly to me that the user not be able to either
> print the pointed object's size, or any of the enum's element, just
> because it is only used via a pointer.

GCC has similar optimizations that might surprise you:

struct foo {
  virtual ~foo();
};

foo f; // GCC and Clang only emits a declaration of 'foo' here

If you make that dtor non-virtual, you'll get a definition. The
optimizations here are founded on the assumption that the whole
program will be built with debug info (in the virtual example above,
we know the type has a key function that must be defined /somewhere/
so just emit the full definition of the type when we emit the
definition of that key function - in the case of Clang's optimization
the assumption is that /some/ translation unit in the program will
dereference the pointer, and at that point we'll emit the definition
of the type). These assumptions are worth a substantial amount (easily
10s of percent of unlinked debug info size - and only less in the
linked case if you use type units) and have clear value to many users.

>  I also seems strange to me
> that an unused typedef is enough to trigger full debug info generation,
> while a variable indirectly referencing a type is not.

(as mentioned, it's actually a global variable of the type, rather
than a typedef)

The way Clang works is that any action that would require the full
definition of the type that was already being emitted, causes the full
definition to be emitted, if that makes sense (I can provide
examples/more words - it is a bit hard to articulate clearly).

> That's why I suggested that we keep the current testcase as is,
> with an xfail with clang, and create a new one if we want to, that
> tests the behavior with the proposed work around.
>
> That's only my opinion, however; it would be fine for the change
> to go in if other maintainers disagree with me and approve the change.

Fair enough - I think the conversation's useful in any case, to help
understand how these different priorities coexist within the project.

- David