Hi,
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.
> 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?
> 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.
That is new in GCC11, don't have GCC10 here to compare against, but
GCC9 produces:
DWARF section [27] '.debug_info' at offset 0x30b5:
[Offset]
Compilation unit at offset 0:
Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4
Unit type: compile (1)
[ c] compile_unit abbrev: 1
producer (strp) "GNU C++17 9.3.1 20200408 (Red Hat
9.3.1-2) -mtune=generic -march=x86-64 -gdwarf-5 -O2 -std=gnu++17"
language (data1) C_plus_plus_14 (33)
name (strp) "p.cc"
comp_dir (strp) "/tmp"
ranges (sec_offset) range list [ c]
low_pc (addr) 000000000000000000
stmt_list (sec_offset) 0
[ 2a] variable abbrev: 2
name (string) "var"
decl_file (data1) p.cc (1)
decl_line (data1) 1
decl_column (data1) 18
type (ref4) [ 3f]
external (flag_present) yes
inline (data1) declared_inlined (3)
const_value (data1) 42
[ 38] base_type abbrev: 3
byte_size (data1) 4
encoding (data1) signed (5)
name (string) "int"
[ 3f] const_type abbrev: 4
type (ref4) [ 38]
[ 44] subprogram abbrev: 5
external (flag_present) yes
name (strp) "main"
decl_file (data1) p.cc (1)
decl_line (data1) 2
decl_column (data1) 5
type (ref4) [ 38]
low_pc (addr) 0x0000000000401050 <main>
high_pc (data8) 6 (0x0000000000401056 <_start>)
frame_base (exprloc)
[ 0] call_frame_cfa
call_all_calls (flag_present) yes
> 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 would say yes. If it is used a user might want to look up its value.
Cheers,
Mark
