On 8/25/20 5:19 AM, Mark Wielaard wrote:
On Mon, 2020-08-24 at 17:38 -0400, Jason Merrill wrote:
This looks incorrect to me, that is a workaround for a real GCC bug.
Shouldn't we instead do something like (untested) following patch?
I mean, for DWARF < 5 the static data members were using DW_TAG_member,
which has been always marked by the function, so IMHO we should also always
mark the DW_TAG_variables at the class scope that replaced those.
The earlier behavior seems like an accident, that happened because we
always need to emit information about non-static data members. I don't
think we should take it as guidance.
Maybe the reason they got emitted this way was an accident on the GCC
side. But I don't think it is an accident on the GDB side. At least
looking at the various gdb testcases, the intention is to show a
struct/class type as defined to the user, which includes both the
static and non-static data members of a class.
That would make sense.
In this case one reason we don't emit debug info is because (before
C++17) there's no definition of 'b'. After C++17 the in-class
declaration of 'b' is a definition, but we don't have to give it a
symbol, so there's still nothing for the debug info to describe.
But don't we describe other parts of a type that don't have a symbol as
part of the debug info?
It seems that currently we describe unused/undefined functions, but not
unused nested types/typedefs.
On 8/25/20 8:41 AM, Jakub Jelinek wrote:
On Mon, Aug 24, 2020 at 05:38:28PM -0400, Jason Merrill via Gcc-patches wrote:
This issue doesn't seem specific to class members; it also affects
namespace-scope C++17 inline variables:
inline const int var = 42;
int main() { return var; }
Compiling this testcase with -g doesn't emit any debug info for 'var' even
though it's used.
Should we assume that if a variable with DW_AT_const_value is TREE_USED, we
need to write out debug info for it?
I guess it is a question of how exactly the (default on)
-feliminate-unused-debug-symbols should behave with different kind of
entities.
One thing are the non-inline static data members without const/constexpr or
without initializer in the class. Those need a definition if they are ever
used, so it is probably fine to only emit them in the class in the TU where
they are defined. But note that e.g. with -fdebug-types-section we still
force them to be output in class and do no pruning (and the pruning actually
makes dwz less efficient unless dwz is tought to not only merge the DIEs
with the same children and attributes, but also reconstruct more complete
DIEs out of several less complete ones for the same class).
Right, this gets at Mark's point above. How much pruning do we want to
do of class bodies? We currently do some, but how much benefit does
that actually give us? Is it worth the cost?
Another case is non-inline static const data member with initializer,
do we track non-odr uses e.g. during constant evaluation and if so, should
that result in the static data member appearing? Because if the static
const data member with initializer is never odr used, it doesn't have to be
ever defined and so it might never appear in the debug info.
Another case are inline vars, shall we treat as being used just that they
were used in some constant expression, or do only odr uses count?
If the goal of debug info is to be able to evaluate the same expressions
that appear in the source, constant uses need to count, too. I wonder
how we could associate the uses with their context so pruning works
properly.
Jason
