This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] [gdb/testsuite] include a use of the definition of a type to cause clang to emit debug info
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Eric Christopher <echristo at gmail dot com>
- Cc: David Blaikie <dblaikie at gmail dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Mon, 14 Apr 2014 11:16:23 -0700
- Subject: Re: [patch] [gdb/testsuite] include a use of the definition of a type to cause clang to emit debug info
- Authentication-results: sourceware.org; auth=none
- References: <CAENS6EvK8+AUQrj_0q2vAz0JH-5Pt0Z=cRWtW--4pyyUTP3WfQ at mail dot gmail dot com> <20140414131050 dot GR4250 at adacore dot com> <CALehDX48=_WQgGgBhogVzM=bQWTXd07NyKUizbdsyNFA9yX+bg at mail dot gmail dot com>
> > 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. If it stops working
thanks to a GCC "optimization", I would like to know about it (personally).
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. 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.
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.
--
Joel