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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Fri, 09 Dec 2011 21:19:37 +0100, Tom Tromey wrote:
> 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

I agree that TU (.debug_types content) is unused there.  IMO that TU can be
completely ignored.


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

I do not think it is problem.  It is read in, but it has bogus nesting:

 <1><51>: Abbrev Number: 13 (DW_TAG_class_type)
    <52>   DW_AT_name        : A
    <54>   DW_AT_declaration : 1
 <2><58>: Abbrev Number: 6 (DW_TAG_subprogram)
    <59>   DW_AT_name        : (indirect string, offset: 0x0): func
    <5f>   DW_AT_type        : <0x65>
    <64>   DW_AT_declaration : 1
 <1><83>: Abbrev Number: 14 (DW_TAG_subprogram)
    <84>   DW_AT_specification: <0x58>
    <88>   DW_AT_low_pc      : 0xb
    <90>   DW_AT_high_pc     : 0x16
    <98>   DW_AT_frame_base  : 1 byte block: 9c         (DW_OP_call_frame_cfa)
[filtered a bit]

(gdb) p 'A::func()' 
$2 = {int (void)} 0x4004df <A::func()>

Going to file it to GCC debug/ .  I believe with proper GCC debug/ it would
work.  Not sure now why it worked before but it probably does not matter.


> 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.

GCC did not use that TU here so we also should not I think.


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

I do not think it is a bug.  GDB in general does not care about declarations,
only about definitions.


Thanks,
Jan