Re: Regression for gdb.base/sigstep.exp with .debug_types

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan>  list static-method.cc:xxx::(anonymous namespace)::A::func
Jan> -26           static int func (void) { return 0; } // xxx::A::func
Jan> -(gdb) PASS: gdb.cp/static-method.exp: list
Jan> static-method.cc:xxx::(anonymous namespace)::A::func
Jan> +Function "xxx::(anonymous namespace)::A::func" not defined in
Jan> "static-method.cc".
Jan> +(gdb) FAIL: gdb.cp/static-method.exp: list
Jan> static-method.cc:xxx::(anonymous namespace)::A::func

I am not completely sure this is a bug.

In this case, g++ puts the class "A" into a .debug_types TU.
There is no link from the .debug_info CU to this TU -- the first thing I
don't understand, I would have expected something.

Second, the CU looks like this:

 <2><38>: Abbrev Number: 10 (DW_TAG_namespace)
    <39>   DW_AT_sibling     : <0x49>	
[...]
 <1><51>: Abbrev Number: 13 (DW_TAG_class_type)
    <52>   DW_AT_name        : A	
    <54>   DW_AT_declaration : 1	
    <54>   DW_AT_sibling     : <0x65>	
 <2><58>: Abbrev Number: 6 (DW_TAG_subprogram)
    <59>   DW_AT_name        : (indirect string, offset: 0x0): func	
    <5d>   DW_AT_decl_file   : 1	
    <5e>   DW_AT_decl_line   : 26	
    <5f>   DW_AT_type        : <0x65>	
    <63>   DW_AT_accessibility: 1	(public)
    <64>   DW_AT_declaration : 1	


Here, "A" is a declaration without a size, so it is ignored by
process_structure_scope.


Now consider the linespec:

    static-method.cc:xxx::(anonymous namespace)::A::func

This means to find definitions of "xxx::(anonymous namespace)::A::func"
defined in static-method.cc.

There are two definitions of this function in the debuginfo.

One is in the CU, but it is ignored when reading debuginfo because class
A is dropped.

One is in the TU, but it is ignored because TUs do not have line
headers, and so the symtab is anonymous -- and so doesn't match
"static-method.cc".


So, what to do?

Perhaps g++ is wrong not to emit some CU->TU linkage.  If this existed
then maybe we could make a symbol in the CU pointing to the type,
presumably making this test work.

Perhaps the DW_AT_declaration treatment in process_structure_scope is a
bug -- but I would be cautious about changing this before a release.

Let me know what you think.

Tom